Convert Clang over to resuming from landing pads with llvm.eh.resume.
It's quite likely that this will explode, but I need to know how. :)

llvm-svn: 132269
diff --git a/clang/lib/CodeGen/CGException.cpp b/clang/lib/CodeGen/CGException.cpp
index 6cb9599..e8ad6da 100644
--- a/clang/lib/CodeGen/CGException.cpp
+++ b/clang/lib/CodeGen/CGException.cpp
@@ -112,11 +112,18 @@
   return CGF.CGM.CreateRuntimeFunction(FTy, "__cxa_call_unexpected");
 }
 
-llvm::Constant *CodeGenFunction::getUnwindResumeOrRethrowFn() {
-  const llvm::Type *Int8PtrTy = llvm::Type::getInt8PtrTy(getLLVMContext());
+llvm::Constant *CodeGenFunction::getUnwindResumeFn() {
   const llvm::FunctionType *FTy =
-    llvm::FunctionType::get(llvm::Type::getVoidTy(getLLVMContext()), Int8PtrTy,
-                            /*IsVarArgs=*/false);
+    llvm::FunctionType::get(VoidTy, Int8PtrTy, /*IsVarArgs=*/false);
+
+  if (CGM.getLangOptions().SjLjExceptions)
+    return CGM.CreateRuntimeFunction(FTy, "_Unwind_SjLj_Resume");
+  return CGM.CreateRuntimeFunction(FTy, "_Unwind_Resume");
+}
+
+llvm::Constant *CodeGenFunction::getUnwindResumeOrRethrowFn() {
+  const llvm::FunctionType *FTy =
+    llvm::FunctionType::get(VoidTy, Int8PtrTy, /*IsVarArgs=*/false);
 
   if (CGM.getLangOptions().SjLjExceptions)
     return CGM.CreateRuntimeFunction(FTy, "_Unwind_SjLj_Resume_or_Rethrow");
@@ -354,13 +361,17 @@
 }
 
 llvm::Value *CodeGenFunction::getExceptionSlot() {
-  if (!ExceptionSlot) {
-    const llvm::Type *i8p = llvm::Type::getInt8PtrTy(getLLVMContext());
-    ExceptionSlot = CreateTempAlloca(i8p, "exn.slot");
-  }
+  if (!ExceptionSlot)
+    ExceptionSlot = CreateTempAlloca(Int8PtrTy, "exn.slot");
   return ExceptionSlot;
 }
 
+llvm::Value *CodeGenFunction::getEHSelectorSlot() {
+  if (!EHSelectorSlot)
+    EHSelectorSlot = CreateTempAlloca(Int32Ty, "ehselector.slot");
+  return EHSelectorSlot;
+}
+
 void CodeGenFunction::EmitCXXThrowExpr(const CXXThrowExpr *E) {
   if (!E->getSubExpr()) {
     if (getInvokeDest()) {
@@ -563,47 +574,59 @@
   return LP;
 }
 
+// This code contains a hack to work around a design flaw in
+// LLVM's EH IR which breaks semantics after inlining.  This same
+// hack is implemented in llvm-gcc.
+//
+// The LLVM EH abstraction is basically a thin veneer over the
+// traditional GCC zero-cost design: for each range of instructions
+// in the function, there is (at most) one "landing pad" with an
+// associated chain of EH actions.  A language-specific personality
+// function interprets this chain of actions and (1) decides whether
+// or not to resume execution at the landing pad and (2) if so,
+// provides an integer indicating why it's stopping.  In LLVM IR,
+// the association of a landing pad with a range of instructions is
+// achieved via an invoke instruction, the chain of actions becomes
+// the arguments to the @llvm.eh.selector call, and the selector
+// call returns the integer indicator.  Other than the required
+// presence of two intrinsic function calls in the landing pad,
+// the IR exactly describes the layout of the output code.
+//
+// A principal advantage of this design is that it is completely
+// language-agnostic; in theory, the LLVM optimizers can treat
+// landing pads neutrally, and targets need only know how to lower
+// the intrinsics to have a functioning exceptions system (assuming
+// that platform exceptions follow something approximately like the
+// GCC design).  Unfortunately, landing pads cannot be combined in a
+// language-agnostic way: given selectors A and B, there is no way
+// to make a single landing pad which faithfully represents the
+// semantics of propagating an exception first through A, then
+// through B, without knowing how the personality will interpret the
+// (lowered form of the) selectors.  This means that inlining has no
+// choice but to crudely chain invokes (i.e., to ignore invokes in
+// the inlined function, but to turn all unwindable calls into
+// invokes), which is only semantically valid if every unwind stops
+// at every landing pad.
+//
+// Therefore, the invoke-inline hack is to guarantee that every
+// landing pad has a catch-all.
+enum CleanupHackLevel_t {
+  /// A level of hack that requires that all landing pads have
+  /// catch-alls.
+  CHL_MandatoryCatchall,
+
+  /// A level of hack that requires that all landing pads handle
+  /// cleanups.
+  CHL_MandatoryCleanup,
+
+  /// No hacks at all;  ideal IR generation.
+  CHL_Ideal
+};
+const CleanupHackLevel_t CleanupHackLevel = CHL_MandatoryCleanup;
+
 llvm::BasicBlock *CodeGenFunction::EmitLandingPad() {
   assert(EHStack.requiresLandingPad());
 
-  // This function contains a hack to work around a design flaw in
-  // LLVM's EH IR which breaks semantics after inlining.  This same
-  // hack is implemented in llvm-gcc.
-  //
-  // The LLVM EH abstraction is basically a thin veneer over the
-  // traditional GCC zero-cost design: for each range of instructions
-  // in the function, there is (at most) one "landing pad" with an
-  // associated chain of EH actions.  A language-specific personality
-  // function interprets this chain of actions and (1) decides whether
-  // or not to resume execution at the landing pad and (2) if so,
-  // provides an integer indicating why it's stopping.  In LLVM IR,
-  // the association of a landing pad with a range of instructions is
-  // achieved via an invoke instruction, the chain of actions becomes
-  // the arguments to the @llvm.eh.selector call, and the selector
-  // call returns the integer indicator.  Other than the required
-  // presence of two intrinsic function calls in the landing pad,
-  // the IR exactly describes the layout of the output code.
-  //
-  // A principal advantage of this design is that it is completely
-  // language-agnostic; in theory, the LLVM optimizers can treat
-  // landing pads neutrally, and targets need only know how to lower
-  // the intrinsics to have a functioning exceptions system (assuming
-  // that platform exceptions follow something approximately like the
-  // GCC design).  Unfortunately, landing pads cannot be combined in a
-  // language-agnostic way: given selectors A and B, there is no way
-  // to make a single landing pad which faithfully represents the
-  // semantics of propagating an exception first through A, then
-  // through B, without knowing how the personality will interpret the
-  // (lowered form of the) selectors.  This means that inlining has no
-  // choice but to crudely chain invokes (i.e., to ignore invokes in
-  // the inlined function, but to turn all unwindable calls into
-  // invokes), which is only semantically valid if every unwind stops
-  // at every landing pad.
-  //
-  // Therefore, the invoke-inline hack is to guarantee that every
-  // landing pad has a catch-all.
-  const bool UseInvokeInlineHack = true;
-
   for (EHScopeStack::iterator ir = EHStack.begin(); ; ) {
     assert(ir != EHStack.end() &&
            "stack requiring landing pad is nothing but non-EH scopes?");
@@ -736,16 +759,23 @@
     EHSelector.append(EHFilters.begin(), EHFilters.end());
 
     // Also check whether we need a cleanup.
-    if (UseInvokeInlineHack || HasEHCleanup)
-      EHSelector.push_back(UseInvokeInlineHack
+    if (CleanupHackLevel == CHL_MandatoryCatchall || HasEHCleanup)
+      EHSelector.push_back(CleanupHackLevel == CHL_MandatoryCatchall
                            ? getCatchAllValue(*this)
                            : getCleanupValue(*this));
 
   // Otherwise, signal that we at least have cleanups.
-  } else if (UseInvokeInlineHack || HasEHCleanup) {
-    EHSelector.push_back(UseInvokeInlineHack
+  } else if (CleanupHackLevel == CHL_MandatoryCatchall || HasEHCleanup) {
+    EHSelector.push_back(CleanupHackLevel == CHL_MandatoryCatchall
                          ? getCatchAllValue(*this)
                          : getCleanupValue(*this));
+
+  // At the MandatoryCleanup hack level, we don't need to actually
+  // spuriously tell the unwinder that we have cleanups, but we do
+  // need to always be prepared to handle cleanups.
+  } else if (CleanupHackLevel == CHL_MandatoryCleanup) {
+    // Just don't decrement LastToEmitInLoop.
+
   } else {
     assert(LastToEmitInLoop > 2);
     LastToEmitInLoop--;
@@ -758,6 +788,10 @@
     Builder.CreateCall(CGM.getIntrinsic(llvm::Intrinsic::eh_selector),
                        EHSelector.begin(), EHSelector.end(), "eh.selector");
   Selection->setDoesNotThrow();
+
+  // Save the selector value in mandatory-cleanup mode.
+  if (CleanupHackLevel == CHL_MandatoryCleanup)
+    Builder.CreateStore(Selection, getEHSelectorSlot());
   
   // Select the right handler.
   llvm::Value *llvm_eh_typeid_for =
@@ -833,22 +867,13 @@
 
     // If there was a cleanup, we'll need to actually check whether we
     // landed here because the filter triggered.
-    if (UseInvokeInlineHack || HasEHCleanup) {
-      llvm::BasicBlock *RethrowBB = createBasicBlock("cleanup");
+    if (CleanupHackLevel != CHL_Ideal || HasEHCleanup) {
       llvm::BasicBlock *UnexpectedBB = createBasicBlock("ehspec.unexpected");
 
-      llvm::Constant *Zero = llvm::ConstantInt::get(Builder.getInt32Ty(), 0);
+      llvm::Constant *Zero = llvm::ConstantInt::get(Int32Ty, 0);
       llvm::Value *FailsFilter =
         Builder.CreateICmpSLT(SavedSelection, Zero, "ehspec.fails");
-      Builder.CreateCondBr(FailsFilter, UnexpectedBB, RethrowBB);
-
-      // The rethrow block is where we land if this was a cleanup.
-      // TODO: can this be _Unwind_Resume if the InvokeInlineHack is off?
-      EmitBlock(RethrowBB);
-      Builder.CreateCall(getUnwindResumeOrRethrowFn(),
-                         Builder.CreateLoad(getExceptionSlot()))
-        ->setDoesNotReturn();
-      Builder.CreateUnreachable();
+      Builder.CreateCondBr(FailsFilter, UnexpectedBB, getRethrowDest().getBlock());
 
       EmitBlock(UnexpectedBB);
     }
@@ -863,7 +888,7 @@
     Builder.CreateUnreachable();
 
   // ...or a normal catch handler...
-  } else if (!UseInvokeInlineHack && !HasEHCleanup) {
+  } else if (CleanupHackLevel == CHL_Ideal && !HasEHCleanup) {
     llvm::Value *Type = EHSelector.back();
     EmitBranchThroughEHCleanup(EHHandlers[Type]);
 
@@ -1440,14 +1465,39 @@
   // This can always be a call because we necessarily didn't find
   // anything on the EH stack which needs our help.
   llvm::StringRef RethrowName = Personality.getCatchallRethrowFnName();
-  llvm::Constant *RethrowFn;
-  if (!RethrowName.empty())
-    RethrowFn = getCatchallRethrowFn(*this, RethrowName);
-  else
-    RethrowFn = getUnwindResumeOrRethrowFn();
+  if (!RethrowName.empty()) {
+    Builder.CreateCall(getCatchallRethrowFn(*this, RethrowName),
+                       Builder.CreateLoad(getExceptionSlot()))
+      ->setDoesNotReturn();
+  } else {
+    llvm::Value *Exn = Builder.CreateLoad(getExceptionSlot());
 
-  Builder.CreateCall(RethrowFn, Builder.CreateLoad(getExceptionSlot()))
-    ->setDoesNotReturn();
+    switch (CleanupHackLevel) {
+    case CHL_MandatoryCatchall:
+      // In mandatory-catchall mode, we need to use
+      // _Unwind_Resume_or_Rethrow, or whatever the personality's
+      // equivalent is.
+      Builder.CreateCall(getUnwindResumeOrRethrowFn(), Exn)
+        ->setDoesNotReturn();
+      break;
+    case CHL_MandatoryCleanup: {
+      // In mandatory-cleanup mode, we should use llvm.eh.resume.
+      llvm::Value *Selector = Builder.CreateLoad(getEHSelectorSlot());
+      Builder.CreateCall2(CGM.getIntrinsic(llvm::Intrinsic::eh_resume),
+                          Exn, Selector)
+        ->setDoesNotReturn();
+      break;
+    }
+    case CHL_Ideal:
+      // In an idealized mode where we don't have to worry about the
+      // optimizer combining landing pads, we should just use
+      // _Unwind_Resume (or the personality's equivalent).
+      Builder.CreateCall(getUnwindResumeFn(), Exn)
+        ->setDoesNotReturn();
+      break;
+    }
+  }
+
   Builder.CreateUnreachable();
 
   Builder.restoreIP(SavedIP);