This was once used in lldb but no longer is. I'm cannot find any other
users, so I'm removing it as a small part of cleaning up and simplifying
the SIL linking process.
If we already have a call graph built, we should add any newly
deserialized functions to it. This is happening in other places we're
deserializing, but wasn't happening in the linking pass, and we've been
getting away with it because we invalidate the entire call graph and
rebuild it when we next need it.
An upcoming change will invalidate only the call graph node for the
current function, so we really need to add these new functions to the
call graph as we deserialize them.
This feature is required for the implementation of pre-specialization, because one needs to check if a specialized SIL function with a given name exists in the standard library.
Swift SVN r30307
The callback (which is used for creating CG nodes) was lost when deserializing the functions of a vtable.
Fixes rdar://problem/21609902
Swift SVN r29838
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
We no longer need or use it since we can always refer to the same bit on
the applied function when deciding whether to inline during mandatory
inlining.
Resolves rdar://problem/19478366.
Swift SVN r26534
Before, providing a full SILFunction declaration object with a proper SILType was the only way to link a function. And constructing such a SILFunction declaration by hand using low-level SIL APIs is very annoying and requires a lot of code to be written. This new linkFunction API allows for a lookup using SILDeclRef and essentially performs linking of a SILFunction by its mangled name (assuming this name is unique), which is much easier to invoke. The new API is useful, e.g. when you need to link a well-known function from a standard library.
Swift SVN r26252
This is only used by SILModule but is not integral to a SILModule so it makes
sense to have it in its own file. It keeps SILModule.cpp more focused. We still
keep it in a private header though since it is only meant to be used by
SILModule.cpp.
Swift SVN r25985
