There was a (commented out) assert that the entry node to each SCC we
find would be a SILArgument. This is not always the case, so I removed
the assert and added a test case that demonstrates this.
I tightened up the IV recognition code a little bit as well.
Swift SVN r19885
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
Fix some comment styles while we are there.
This commit needs a recent version of puzzle/master llvm because I need to make
to const expose the basic block map in the LoopInfo class.
Swift SVN r19630
Also fixed a small bug related to how we handle arguments. We were not
clearing the state of the argument when we saw a potential decrement of
the argument.
<rdar://problem/17013194>
Swift SVN r18706
This commit fixes a bunch of problems I found in TBAA. Some fun
examples:
1. We were not handling protocols correctly.
2. We were not handling enums correctly.
3. We were not handling builtins correctly all the time.
...
And much more.
I also added a fairly exhaustive test.
Additionally I checked the benchmarks and did not see any regressions.
rdar://16651852
Swift SVN r18148
The reason that this is important is that we *ARE* allowing the stdlib
to perform certain types of type punning for efficiency implying we need
to have a type oracle instruction to have safety.
A type oracle instruction is an instruction which implies undefined behavior
unless its operand/result is of a certain type (allowing us to ignore that
possibility).
In a following commit I am going to go over and fix any problems in the
actual TBAA implementation and give all the various checks tests.
rdar://16651852
Swift SVN r18090
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
