This is a separate optimization that detects short-lived temporaries that can be eliminated.
This is necessary now that SILGen no longer performs basic RValue forwarding in some cases.
SR-5508: Performance regression in benchmarks caused by removing SILGen peephole for LoadExpr in +0 context
This bug was caught by the SIL verifier. Any invocation of a NoReturn function should be followed by an `unreachable` instruction.
Fixes rdar://problem/33591235
Instead of having the complicated logic of finding the end of an object's lifetime we now use the existing ValueLifetimeAnalysis and StackNesting tools.
This simplifies the implementation a lot and does not use dominator and post-dominator trees anymore.
It's not a NFC because the way how to ensure proper nesting of stack allocations is now different.
To correct the stack nesting, the deallocations are moved down (instead of moving the allocations up).
Also it's now required that there is a final release for the allocation on all paths (which was not the case in some hand-written SIL tests).
Computation of dead-end blocks and escape analysis are now only done on demand. This saves compile time in case a function has no alloc_refs at all.
In dead-array elimination we assume that the array allocation is post-dominated by all its final releases.
The only exception are branches to dead-end ("unreachable") blocks. So we just ignored all paths which didn't end up in a final release.
Now we explicitly pass the set of dead-end blocks and just ignore those blocks.
This is safer and it's also needed in the upcoming re-write of StackPromotion.
This patch started with a suggestion from Adrian Prantl to adapt to
LLVM r307953. The code has changed more since then so I modified it
to get it to build and I also fixed up StackPromotion to deal with related
changes. (I did not search back very far but it looks like the StackPromotion
change may have been a latent bug that did not matter much until recent
changes started using the function parameter.)
1) PostOrderAnalysis is not invalidated after splitting critical edges. This let the data flow solver omit new inserted blocks.
2) Handle infinite loops in the CFG correctly. So that we don’t insert random release instructions into such CFG pathes.
https://bugs.swift.org/browse/SR-5187
rdar://problem/32713742
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.
