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
Reapply r24765 with small tweak to comment. This was reverted in r24766.
It turns out that this particular change does not interfere with any
assumptions made in the function signature optimization pass.
Swift SVN r24804
NFC since we're only building the call graph from function_refs now, and
thus we know we always have a complete set of callees (exactly one).
Swift SVN r24792
This reverts commit r24765.
There might be an issue with some of the clients of the call graph
making assumptions that this change invalidates.
Swift SVN r24766
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
