The old call graph remains, but the new call graph can obtained by
calling getCallGraph() on the analysis pass.
I'll move the few other passes that use the call graph over soon and
then rip out the old call graph.
No diffs in the stdlib.
Swift SVN r21565
With this change we generate the SCCs in the call graph (for the kinds
of calls we currently recognize) in bottom-up, which we can then
iterate over directly or in reverse for invocation- and
reverse-invocation-order traversal of the call graph.
(This still isn't hooked up - but will be after some dumping routines
and verification of the output).
Swift SVN r21552
This enables us to both check if any instructions may use or decrement a value
in an instruction range and if we find such an instruction know the furthest
where we can move the retain or release.
Swift SVN r21522
Sinking retains will simply make the unique check useless and eliminate
Array copies even when we need them.
Fix for:
<rdar://problem/18109082> ARC: make _isUniquelyReferenced a barrier to avoid lost copies
Swift SVN r21485
This will allow us to search in the order the roots are added which
should improve stability of our output. There is also an ordinal on each
node that we can use to choose order of traversing edges at a given call
site.
Swift SVN r21484
Previously we tracked a set of functions that could be called from a given
call site. Now we track a set of call graph nodes (each of which
represents a callable function). As a result we now create call graph
nodes for declarations rather than just definitions.
Swift SVN r21483
This is not yet hooked up. I want to add a dumper and some tests, and
need to implement code to do invocation- and reverse-invocation-ordering
over the SCCs of the call graph before it can fully replace the existing
code.
This call graph has edges for each call site, so it's really a
multigraph. Each call site tracks the set of functions that can be
called from that point. Currently that set is always a singleton since
we only handle applies of direct function_refs (like the existing call
graph). In time it will be expanded to handle other types of function
application.
Swift SVN r21407
We were adding call graph edges based on seeing a function_ref. Instead,
we'll only add them now based on a direct apply of a function_ref.
Also a minor refactoring to move the code that walks the blocks and
instructions of a function into its own method.
Swift SVN r21243
Before this commit we scanned the vtables every time we wanted to know who are the subclasses of a class. Now we scan the vtables just once.
Swift SVN r20847
Use it in loop rotation.
The pattern to update analysis information is:
// The AnalysisInfo was preserved for this function.
if (Changed) {
// Preserve the analyis for this function by decoupling it from the analysis
// cache.
auto PreservedAnalysis = Analysis.preserveAnalysis(Function);
// Invalidate analysis for this function.
PM.invalidateAnalysis(Function, InvalidationKind::CFG);
// Update the preserved analysis for this function.
Analysis.updateAnalysis(F, std::move(PreservedAnalysis));
}
Swift SVN r19918
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 two functions are:
1. valueHasARCUsesInInstructionRange.
2. valueHasARCDecrementsInInstructionRange.
They operate on the range [Start, End).
I am going to use them in enum simplification and sil code motion.
Swift SVN r19893
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
