[PM/LCG] Follow-up fix to r308088 to handle deletion of library

functions.

In the prior commit, we provide ordering to the LCG between functions
and library function definitions that they might begin to call through
transformations. But we still would delete these library functions from
the call graph if they became dead during inlining.

While this immediately crashed, it also exposed a loss of information.
We shouldn't remove definitions of library functions that can still
usefully participate in the LCG-powered CGSCC optimization process. If
new call edges are formed, we want to have definitions to be called.

We can still remove these functions if truly dead using global-dce, etc,
but removing them during the CGSCC walk is premature.

This fixes a crash in the new PM when optimizing some unusual libraries
that end up with "internal" lib functions such as the code in the "R"
language's libraries.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@308417 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
Chandler Carruth
2017-07-19 04:12:25 +00:00
parent 17d4e087c3
commit ee48043ceb
4 changed files with 48 additions and 7 deletions
+6 -1
View File
@@ -144,7 +144,7 @@ LazyCallGraph::LazyCallGraph(Module &M, TargetLibraryInfo &TLI) {
// synthesize reference edges to it to model the fact that LLVM can turn
// arbitrary code into a library function call.
if (isKnownLibFunction(F, TLI))
LibFunctions.push_back(&F);
LibFunctions.insert(&F);
if (F.hasLocalLinkage())
continue;
@@ -1608,6 +1608,11 @@ void LazyCallGraph::removeDeadFunction(Function &F) {
assert(F.use_empty() &&
"This routine should only be called on trivially dead functions!");
// We shouldn't remove library functions as they are never really dead while
// the call graph is in use -- every function definition refers to them.
assert(!isLibFunction(F) &&
"Must not remove lib functions from the call graph!");
auto NI = NodeMap.find(&F);
if (NI == NodeMap.end())
// Not in the graph at all!