when inlining something like this:

define void @f3(void (i8*)* %__f) ssp {
entry:
  call void %__f(i8* undef)
  unreachable
}

define void @f4(i8* %this) ssp align 2 {
entry:
  call void @f3(void (i8*)* @f2) ssp
  ret void
}

The inliner is turning the indirect call to %__f into a direct
call to F2.  Make the call graph more precise when this happens.

The inliner doesn't revisit call sites introduced by inlining,
so there isn't an easy way to test for this, but a more precise
callgraph is a good thing.




git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102131 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
Chris Lattner 2010-04-22 21:31:00 +00:00
parent c04d54527e
commit b957a5e41e

View File

@ -200,8 +200,22 @@ static void UpdateCallGraphAfterInlining(CallSite CS,
// If the call was inlined, but then constant folded, there is no edge to
// add. Check for this case.
if (Instruction *NewCall = dyn_cast<Instruction>(VMI->second))
CallerNode->addCalledFunction(CallSite::get(NewCall), I->second);
Instruction *NewCall = dyn_cast<Instruction>(VMI->second);
if (NewCall == 0) continue;
// It's possible that inlining the callsite will cause it to go from an
// indirect to a direct call by resolving a function pointer. If this
// happens, set the callee of the new call site to a more precise
// destination. This can also happen if the call graph node of the caller
// was just unnecessarily imprecise.
if (I->second->getFunction() == 0)
if (Function *F = CallSite(NewCall).getCalledFunction()) {
// Indirect call site resolved to direct call.
CallerNode->addCalledFunction(CallSite::get(NewCall), CG[F]);
continue;
}
CallerNode->addCalledFunction(CallSite::get(NewCall), I->second);
}
// Update the call graph by deleting the edge from Callee to Caller. We must