This is one step towards removing the full call graph. In the process it
removes a bit of brittleness around side effect analysis queries which
previously may or may not have returned the most conservative result
depending on whether we already had a valid call graph constructed.
We need to be able to support non-apply instructions that result in
calling things like deinits. This is the first mechanical pass of
converting interfaces and data over.
Thanks to Arnold and Roman for investigating a memory problem, which was completely unrelated but
caused enough panic on my side to find this one :-)
Swift SVN r32956
There is now a separate class to abstract the notion of a set of
callees. The class itself is very compact - always a pointer in size,
but distinguishes singleton callees, true sets of callees, and in the set
case whether that set is incomplete. The sets are cached in the call
graph as before, but that cache now caches whether the sets are
incomplete or not, which will enable correctly computing and caching
that information for method calls so that the call graph can correctly
represent whether those are known to be incomplete sets, or whether we
really know all the possible callees at a call site.
This also hides more implementation details of the call graph, and
provides a new interface getCallees() which provides a way to iterate
over the SILFunctions rather than CallGraphNodes.
More clean-up and refactoring coming in future commits.
Swift SVN r32737
Rename the getPartial* functions to get* in each case.
The intent in splitting these into two APIs was to catch bugs, but it
adds complexity without really adding much safety since a client could
call getPartial* and treat the results as if they are complete.
Swift SVN r32685
Add one of the queries returning call sites of callers of a function
into the CallGraph proper.
Another of many refactoring steps on the way. NFC.
Swift SVN r32589
This avoids quadratic complexity if a function pass does invalidate the call graph.
(which should not happen anyway, but this is another issue).
Swift SVN r31993
It provides side-effect information for functions, e.g. does it write to memory, etc.
For details see the comments in SideEffectAnalysis.h
With this commit, the side-effect analysis is just computed but not used anywhere yet.
So, regarding the generated code it is NFC.
Swift SVN r31951