GC poses hazards to the inliner. Consider:

    define void @f() {
            ...
            call i32 @g()
            ...
    }

    define void @g() {
            ...
    }

The hazards are:

  - @f and @g have GC, but they differ GC. Inlining is invalid. This
    may never occur.
  - @f has no GC, but @g does. g's GC must be propagated to @f.

The other scenarios are safe:

  - @f and @g have the same GC.
  - @f and @g have no GC.
  - @g has no GC.

This patch adds inliner checks for the former two scenarios.

llvm-svn: 45351

1 files changed, 13 insertions, 0 deletions

diff --git a/llvm/lib/Transforms/Utils/InlineFunction.cpp b/llvm/lib/Transforms/Utils/InlineFunction.cpp
index dba0e69a355..0a9aa7a8d75 100644
--- a/llvm/lib/Transforms/Utils/InlineFunction.cpp
+++ b/llvm/lib/Transforms/Utils/InlineFunction.cpp
@@ -201,6 +201,19 @@ bool llvm::InlineFunction(CallSite CS, CallGraph *CG, const TargetData *TD) {
   BasicBlock *OrigBB = TheCall->getParent();
   Function *Caller = OrigBB->getParent();
 
+  
+  // GC poses two hazards to inlining, which only occur when the callee has GC:
+  //  1. If the caller has no GC, then the callee's GC must be propagated to the
+  //     caller.
+  //  2. If the caller has a differing GC, it is invalid to inline.
+  if (CalledFunc->hasCollector()) {
+    if (!Caller->hasCollector())
+      Caller->setCollector(CalledFunc->getCollector());
+    else if (CalledFunc->getCollector() != Caller->getCollector())
+      return false;
+  }
+  
+  
   // Get an iterator to the last basic block in the function, which will have
   // the new function inlined after it.
   //