Add a small verification method that checks that we run our function analysis
only on functions with bodies (not on external definitions). I ran into this bug
when working on the pass manager.
This is a simple analysis refactored from the call code. It uses the
vtables and witness tables to compute a cache of decl-to-possible-callee
mappings, and provides an interface to look these up for a
FullApplySite, as well as building and returning a singleton list for
function_ref callees.
It adds a new invalidation PreserveKind, 'Functions', which currently
nothing claims to preserve (but most everything actually does). Updating
the preservation claims of existing passes will be done as a separate
step.
This commit also adds a printing pass and test for this analysis.
So far this was done by directly calling PM->getAnalysis() in create*Analysis().
But this required a correct order of analysis definitions in Analysis.def.
Swift SVN r31941
This allows one by editing one place to create an Analysis kind and ensure that
your analysis is properly registered in all of the relevant places for use with
swift/sil-opt.
If we add tools like a sil bugpoint, this will make it easy to add analysis
without having to know about all of these locations.
It also standardizes the create***Analysis API to take a SILModule and a
SILPassManager. All passes take in a SILModule and some take in a
SILPassManager. By standardizing the API and in the cases where SILPassManager
is not used, just making it a dead argument enables metaprogramming.
Swift SVN r31420
It avoids that a pass runs a second time if didn't make any changes in the previous run and no other pass changed the function in between.
rdar://problem/20336764
In this change I also removed the CompleteFunctions analysis which is now obsolete.
Some measurements with swiftbench (-wmo, single threaded):
It reduces the number of pass runs by about 28%. Because only passes are skipped that don't do anything, the effect on compile time is not so dramatic.
The time spent in runSILOptimizationPasses is reduced by ~9% which gives a total compile time reduction of about 3%.
Swift SVN r26757
This commit splits DominanceAnalysis into two analysis (Dom and PDom) that
can be cached and invalidates using the common FunctionAnalysisBase interface
independent of one another.
Swift SVN r26643
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
