We don't want passes directly querying the CallGraph because managing
invalidation will be so difficult.
This is still a workaround for the proper fix to AST/SIL type
substitution: <rdar://problem/21025088> SIL should properly represent
binding dynamic self to generic parameters.
This reverts commit 309f9630a6.
There is some concern this could break things now or in the future so it
makes sense to preemptively revert this until those concerns are
addressed.
We'll now include edges for instructions that can potentially result in
a release (and thus call to a deinit).
Unhandled are release_value and anything involving archetypes, which
will involve more work.
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.
Rather than completely recomputing callee sets in the call graph after
removing dead functions, we should instead remove these functions from
the existing callee sets. Recomputing callee sets can lead to the callee
sets differing from the edges present in the call graph since we are
still doing some deserialization during call graph construction.
This change also updates CallGraphEditor::dropAllReferences() to remove
all the edges from the node representing the function we're dropping
references from because that's a sensible thing to do as part of that
function.
Add a parameter for a function the call site is in, rather than using
the call site to determine the function.
This is necessary for enabling invalidation of call graph information
for individual functions. If we're not maintaining the call graph during
a pass, we may delete an instruction and be left with a dangling pointer
in the call graph edge. This allows us to still remove the edge properly
without trying to look at the instruction it represents.
Change the declaration of the functions that do not modify the call
graph data structure to const to make it easier to know which ones do
modify the call graph at a glance.
Swift SVN r32930
Previously we handled only cases where we had concrete types and knew
exactly what would be called. Now we compute callee sets for the cases
where we have generic types.
We currently default in these cases to assuming we could call unknown
functions. Improving that will come in a future commit.
Swift SVN r32814
Previously we conservatively assumed any class_method call site could
call unknown functions.
With this commit we now determine which call sites really can call
unknown functions. For those that cannot, we know all possible callees,
and can use that fact in interprocedural analyses like side-effect
analysis and capture analysis.
Swift SVN r32772
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
SmallSetVector takes more space than SmallPtrSet, but the number of
these that we actually allocate is bounded by the number of unique
method decls we see in vtables, so total memory usage won't grow by
much.
This allows us to remove the sorting that we're doing at various points
in processing as well as enabling the use of ArrayRefView (in a later
commit) to hide call graph nodes and instead just vend the called
SILFunctions.
Swift SVN r32723
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
OrderedCallGraph, which is only available in debug builds, needs to be a
friend of CallGraph (which will happen in a subsequent commit), so it
cannot go into an anonymous namespace.
Swift SVN r32653
They were being created in reverse order of discovery, resulting in call
sites being renumbered any time new code is added to the end of a file,
which isn't great for testing.
Swift SVN r32464
We only need to know whether a callee set for a class_method is complete
when we go to create the call graph edge, so defer that determination
until that point. This is currently just hard coded to false, but a
subsequent commit will actually make that determination.
Swift SVN r32463
