This adds an analysis to the compiler that identifies types that are may store
to memory on destruction.
It adds a compiler known protocol _DestructorSafeContainer that allows the
standard library to identify containers whose destructor's memory effects
depends strictly on the type parameters of the container.
Array<T> : _DestructorSafeContainer {} may not store to memory during
destruction if the bound T is a type that does not store to memory on
destruction.
This is needed to deduce that for example Array<Array<Int>> is does not store to
memory on destruction (e.g during a call to release).
rdar://18940376
Swift SVN r23242
This is important since to be more aggressive we are ignoring incoming values
that are no-payload enums since as far as we are concerned they do not matter
since retains, releases on those values are no-ops.
Swift SVN r21932
The cache is needed to ensure we do not run into compile time problems once we
start looking through Phi Nodes.
The analysis is currently disabled and just returns
SILValue::stripRCIdentityPreservingOps. I am going to thread it through the rest
of the passes that use that call. Then I am going to hide
stripRCIdentityPreservingArgs. Finally post OzU, I am going to enable the pass.
rdar://18300069
Swift SVN r21891
In the current setup analysis information is not reused by new pass managers.
There is no point in having different pass managers. Instead, we can just remove
transformations, reset the internal state of the pass manager, and add new
transformation passes. Analysis information can be reused.
Reuse one pass manager in the pass pipeline so that we don't have to
unnecessarily recompute analysis information.
Swift SVN r19917
This ensures that if we have a bunch of passes in a row which modify the CFG, we
do not continually rebuild the post order, while at the same time preserving the
property of multiple passes which do not touch the CFG sharing the same post
order, reverse post order rather than recomputing them.
rdar://17654239
Swift SVN r19913
The induction variable analysis derives from the SCC visitor CRTP-style
and uses it to drive analysis to find the IVs of a function.
The current definition of induction variable is very weak, but enough to
use for very basic bounds-check elimination.
This is not quite ready for real use. There is an assert that I've
commented out that is firing but should not be, and that will require
some more investigation.
Swift SVN r19845
See rdar://16676020 for details.
r17101 tries to solve r16761933 by checking non-direct recursions in
the call graph. We are in discussion of solving it in a different way.
Todo: figure out why r17101 causes a preformance regression.
Swift SVN r17265
specialize on polymorphic arguments.
This can be enabled with: -sil-devirt-threshold 500.
It currently improves RC4 (when enabled) by 20%, but will be much more
important after Michael's load elimination with alias analysis lands.
This implementation is suitable for experimentation. Superficial code
reviews are also welcome. Although be warned that the design is overly
complex and I plan to rewrite it. I initially abandoned the idea of
incrementally specializing one function at a time, thinking that we
need to analyze full chains. However, I since realized after talking
to Nadav that the incremental approach can be made to work. A lot of
book-keeping will go away with that change.
TODO:
- Resolve protocol argument types. Currently we assume they can be
reinitialized at applies, but I don't think they can unless they are
@inouts. This is an issue with the existing local devirtualizer
that prevents it working across calls.
- Properly mangle the specialized methods. Find existing
specializations by demangling rather than maintaining a map.
- Rewrite the logic for specializing chains for simplicity.
- Enable by default.
Swift SVN r13642
