Previous attempts to update the callgraph explicitly after calls to
linkFunction() weren't completely effective because we can deserialize
deeply and introduce multiple new function bodies in the process.
This gets us a bit closer, but only adds new call graph nodes. It does
not currently add edges for everything that gets deserialized (and this
is not fatal, so it is a step forward).
Swift SVN r27120
These aren't really orthogonal concerns--you'll never have a @thick @cc(objc_method), or an @objc_block @cc(witness_method)--and we have gross decision trees all over the codebase that try to hopscotch between the subset of combinations that make sense. Stop the madness by eliminating AbstractCC and folding its states into SILFunctionTypeRepresentation. This cleans up a ton of code across the compiler.
I couldn't quite eliminate AbstractCC's information from AST function types, since SIL type lowering transiently created AnyFunctionTypes with AbstractCCs set, even though these never occur at the source level. To accommodate type lowering, allow AnyFunctionType::ExtInfo to carry a SILFunctionTypeRepresentation, and arrange for the overlapping representations to share raw values.
In order to avoid disturbing test output, AST and SILFunctionTypes are still printed and parsed using the existing @thin/@thick/@objc_block and @cc() attributes, which is kind of gross, but lets me stage in the real source-breaking change separately.
Swift SVN r27095
I suspect this is a holdover from when I rewrote most of the call graph
code. In any event, it's unused since we store this in the call graph
itself.
Swift SVN r27072
Use the isPossiblyUsedExternally method of SILFunction, remove a
work-around for "main", and delete a big "how" comment that could easily
be made obsolete (and probably will soon).
Swift SVN r26983
Use FullApplySite rather than ApplyInst through data structures and
function signatures.
This change does not update the call graph to actually look at
TryApply. That will happen in a future change.
Swift SVN r26893
Instead, add a removeEdge() and update code to use
getCallGraphEdge()/removeEdge() in cases where the apply may not be
represented in the call graph.
Swift SVN r26881
Before this commit, passes that were attempting to maintain the call
graph would actually build it if it wasn't already valid, just for the
sake of maintaining it.
Now we only maintain it if we already had a valid call graph built.
Swift SVN r26873
Small tweak to function signature optimization so that it filters out
applies that might have multiple targets, as well as applies of partial
applies, which will take some updates to handle.
Resolves rdar://problem/19632244 and rdar://problem/20049782.
I've opened rdar://problem/20306331 to consider handling
apply-of-partial-apply at some point in the future.
Swift SVN r26585
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
