Reapply "Handle thin_to_thick_function in call graph construction."

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
This commit is contained in:
Mark Lacey
2015-01-28 20:21:45 +00:00
parent 406592e5c2
commit a842e35810
3 changed files with 8 additions and 11 deletions

View File

@@ -11,6 +11,7 @@
//===----------------------------------------------------------------------===//
#include "swift/SILAnalysis/CallGraphAnalysis.h"
#include "swift/Basic/Fallthrough.h"
#include "llvm/ADT/DenseMap.h"
#include "llvm/ADT/SetVector.h"
#include "llvm/ADT/SmallVector.h"
@@ -64,6 +65,9 @@ bool CallGraph::tryGetCalleeSet(SILValue Callee,
bool &Complete) {
switch (Callee->getKind()) {
case ValueKind::ThinToThickFunctionInst:
Callee = cast<ThinToThickFunctionInst>(Callee)->getOperand();
SWIFT_FALLTHROUGH;
case ValueKind::FunctionRefInst: {
auto *CalleeFn = cast<FunctionRefInst>(Callee)->getReferencedFunction();
auto *CalleeNode = getCallGraphNode(CalleeFn);
@@ -82,14 +86,6 @@ bool CallGraph::tryGetCalleeSet(SILValue Callee,
// graph.
return false;
case ValueKind::ThinToThickFunctionInst: {
auto ThinCallee = cast<ThinToThickFunctionInst>(Callee)->getOperand();
// TODO: We want to see through these to the underlying function.
assert(cast<FunctionRefInst>(ThinCallee) && "Expected function reference!");
(void)ThinCallee;
return false;
}
case ValueKind::SILArgument:
// First-pass call-graph construction will not do anything with
// these, but a second pass can potentially statically determine