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
This is due to MayHaveSideEffects encompassing ref count effects and a
myriad of other effects. If/when we separate the two concepts (which is
cleaner IMHO), the flag will no longer be necessary.
Swift SVN r16807
This is because I need them in ARCAnalysis.cpp and from a modeling
perspective it is no longer just going to be used just in AA since they
are of larger functionality.
Swift SVN r16297
that an apply which may decrement ref counts can not decrement a value with
reference semantics if we can prove the value does not alias any of the applies
arguments.
Swift SVN r14120
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
