Move IndexTrieNode from DeadObjectElimination into its own header. I plan to
use this data structure when diagnosing static violations of exclusive access.
Use 'hasAssociatedValues' instead of computing and discarding the
interface type of an enum element decl. This change has specifically not
been made in conditions that use the presence or absence of the
interface type, only conditions that depend on the presence or absence
of associated values in the enum element decl.
If some functions are explicitly annotated by developers as @inline(__always) or @_transparent, they should always be a subject for the inlining of generics, even if this kind of inlining is not enabled currently for all functions.
If some functions are explicitly annotated by developers as @inline(__always) or @_transparent, they should always be a subject for the inlining of generics, even if this kind of inlining is not enabled currently for all functions.
The linkage change let the compiler generate code for public functions which are imported from the stdlib - and are also available in the swiftCore library.
This got worse since we use public linkage for @_versioned internal functions in the stdlib.
Getting rid of the linkage change reduces code size a lot: up to 40% for some projects.
I didn’t see any significant impact on benchmark performance.
A function is pure if it has no side-effects.
If there is a call of a pure function with constant arguments, it always makes sense to inline it, because we know that the whole computation will be constant folded.
Till now createApply, createTryApply, createPartialApply were taking some arguments like SubstCalleeType or ResultType. But these arguments are redundant and can be easily derived from other arguments of these functions. There is no need to put the burden of their computation on the clients of these APIs.
The removal of these redundant parameters simplifies the APIs and reduces the possibility of providing mismatched types by clients, which often happened in the past.
Replace `NameOfType foo = dyn_cast<NameOfType>(bar)` with DRY version `auto foo = dyn_cast<NameOfType>(bar)`.
The DRY auto version is by far the dominant form already used in the repo, so this PR merely brings the exceptional cases (redundant repetition form) in line with the dominant form (auto form).
See the [C++ Core Guidelines](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#es11-use-auto-to-avoid-redundant-repetition-of-type-names) for a general discussion on why to use `auto` to avoid redundant repetition of type names.
1) to find a threading candidate for a branch instruction, look through multiple successor blocks and not only in the immediate successor
2) handle SSA-cycles when getting the case for an enum value
SubstitutionMap::lookupConformance() would map archetypes out
of context to compute a conformance path. Do the same thing
in SubstitutionMap::lookupSubstitution().
The DenseMap of replacement types in a SubstitutionMap now
always has GenericTypeParamTypes as keys.
This simplifies some code and brings us one step closer to
a more efficient representation of SubstitutionMaps.
Specializations are implementation details, and thus shouldn't be
public, even if they are specializing a public function. Without this
downgrade, the ABI of a module depends on random internal code
(could change inlining decisions etc.), as well as swiftc's optimiser.
This consists of just removing support from OME for ensuring that all uses of a
box go through the project_box that has as its user a mark_uninitialized. Since
the lowering of mark_uninitialized onto the relevant project_box is done by
MarkUninitializedFixup pass, I can just rip out the hacks from the OME!
rdar://31521023
I put in a simple fixup pass (MarkUninitializedFixup) for staging purposes. I
don't expect it to be in tree long. I just did not feel comfortable fixing up in
1 commit all of the passes up to DI.
rdar://31521023
At some point, pass definitions were heavily macro-ized. Pass
descriptive names were added in two places. This is not only redundant
but a source of confusion. You could waste a lot of time grepping for
the wrong string. I removed all the getName() overrides which, at
around 90 passes, was a fairly significant amount of code bloat.
Any pass that we want to be able to invoke by name from a tool
(sil-opt) or pipeline plan *should* have unique type name, enum value,
commend-line string, and name string. I removed a comment about the
various inliner passes that contradicted that.
Side note: We should be consistent with the policy that a pass is
identified by its type. We have a couple passes, LICM and CSE, which
currently violate that convention.
In particular, support the following optimizations:
- owned-to-guaranteed
- dead argument elimination
Argument explosion is disabled for generics at the moment as it usually leads to a slower code.
This ensures that the pass manager runs the eliminator on all functions once
before running any further passes. Otherwise, due to the way the pass manager
runs functions, sometimes a function with unqualified ownership is visible from
a function with qualified ownership. This makes it impossible to have an
invariant that a pass either sees an entire qualified or unqualified world. This
is a useful feature that I would like to keep if I can.
rdar://29870610
if the argument is an array literal.
For example:
arr += [1, 2, 3]
is replaced by:
arr.append(1)
arr.append(2)
arr.append(3)
This gives considerable speedups up to 10x (for our micro-benchmarks which test this).
This is based on the work of @ben-ng, who implemented the first version of this optimization (thanks!).
