The old invalidation lattice was incorrect because changes to control flow could cause changes to the
call graph, so we've decided to change the way passes invalidate analysis. In the new scheme, the lattice
is replaced with a list of traits that passes preserve or invalidate. The current traits are Calls and Branches.
Now, passes report which traits they preserve, which is the opposite of the previous implementation where
passes needed to report what they invalidate.
Node: I tried to limit the changes in this commit to mechanical changes to ease the review. I will cleanup some
of the code in a following commit.
Swift SVN r26449
Specifically, addEdgesForApply() and removeEdgesForApply() allow for
clients to notify the call graph of apply instructions that are being
added or removed by the client. This allows us to avoid dangling
pointers in the maps kept in the call graph and avoid invalidating the
entire call graph at the end of passes that choose to maintain it.
Also, markCallerEdgesOfCalleesIncomplete() makes it possible to notify
all the callees of an apply that is being removed that we no longer have
complete information about all of the callers.
What this change specifically does not do is recompute the bottom-up
ordering of SCCs or functions in the call graph.
I have some incomplete updates to the inliner to use this functionality,
and it doesn't appear to be completely broken, but at this point I would
say this is experimental and could change once we have more clients
making use of it.
Swift SVN r26097
Re-apply r26072 with a fix to ensure that we get stable bottom-up
orderings in the call grpah.
Using SmallPtrSet here makes sense, and paves the way to more reasonable
code for editing the call graph by clients.
One unfortunate casualty of this is the ArrayRevView that was used by
one client.
Swift SVN r26093
This reverts commit r26072, which could result in non-deterministic
bottom-up ordering in the call graph.
I'll reapply with a fix soon.
Swift SVN r26074
It makes more sense, and paves the way to more reasonable code for
editing the call graph by clients.
One unfortunate casualty of this is the ArrayRevView that was used by
one client.
Swift SVN r26072
Previously this was scattered in various places . Now we have a simple model that
all CallGraphEdges, CallGraphNodes, and CallGraphSCCs are owned by the CallGraph
since they are allocated by the CallGraph's BumpPtrAllocator.
This additionally fixes a problem where we were calling delete on SCC's owned by
the BumpPtrAllocator.
Swift SVN r25522
This is currently disabled by default since this verification trips on
ToT when I checked a few days ago.
The current checks that are performed are:
1. For every (SILFunction, CallGraphNode) pair FuncPair in the SILFunction to
CallGraphNode map check that:
a. FuncPair.first is a SILFunction in the current module.
b. FuncPair.first is the SILFunction inside the CallGraphNode FuncPair.second.
c. All CallGraphEdges mapped to FuncPair.second have ApplyInsts which are in
the SILFunction FuncPair.first.
2. For every pair (ApplyInst, CallGraphEdge) ApplyPair in the Apply to
CallGraphEdge map, check that:
a. ApplyPair.second.getCallSite() == ApplyPair.first.
b. ApplyPair.first->getFunction() is in the SILFunction to
CallGraphNode map and the CallGraphEdge for ApplyPair is one of
CallSiteEdges in the mapped to CallGraphNode.
<rdar://problem/19944399>
Swift SVN r25520
This makes it easy to use the callgraph to determine what the Apply
actually calls instead of attempting to ascertain it in an adhoc
manner. This allows for the call graph analysis to be used as the one
point of truth for determing what an apply inst can call.
Swift SVN r25516
Small clean-up to try to improve on the clarity of the call graph code.
I think this is an overall improvement although there is still some
clunky naming that could be improved in the future.
Swift SVN r25492
The memory allocation of DenseSet had a significant contribution to the compile time.
This change reduces the time of runSILOptimizationPasses by ~25% in a stdlib build => ~2s faster.
Swift SVN r25373
We specifically only handle cases of functions that are not visible externally
and for whom all function_refs to the function only have apply inst users.
<rdar://problem/19137435>
Swift SVN r23714
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 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
