[PATCH] Handle nested landing pads in outlined catch handlers for Windows C++ EH

[Andy Kaylor]

REPOSITORY
  rL LLVM

================
Comment at: lib/CodeGen/WinEHPrepare.cpp:697-698
@@ +696,4 @@
+  unsigned NumArgs = EHActions->getNumArgOperands();
+  // FIXME: Replace this with a call to parseEHActions when it's ready.
+  for (unsigned i = 0; i < NumArgs; ++i) {
+    Value *V = EHActions->getArgOperand(i);
----------------
rnk wrote:
> parseEHActions is in tree in FunctionLoweringInfo, but if we share this code, we should probably move it over to this pass and declare it in WinEHFuncInfo.h.
> 
> Do you want to do this now or later? I'm OK either way.
It probably doesn't make sense to check in code that's going to be removed almost immediately.  I'm in the process of merging this patch with the latest trunk revision now.  I'll go ahead and make this change while I'm at it.

================
Comment at: lib/CodeGen/WinEHPrepare.cpp:702-723
@@ +701,24 @@
+    // outlined function. Exception variables should always have an alloca.
+    if (auto *AV = dyn_cast<AllocaInst>(V)) {
+      // See if this handler already has a copy of the needed value.
+      bool Found = false;
+      if (FrameVarInfo.count(AV)) {
+        // The FrameVarInfo map may contain references to this variable in
+        // multiple handler functions.  We need to iterate through them to
+        // see if one is in OutlinedHandlerFn.  If so, use that value in the
+        // eh.actions call.
+        for (auto *MappedAV : FrameVarInfo[AV]) {
+          if (MappedAV->getParent()->getParent() == OutlinedHandlerFn) {
+            EHActions->setArgOperand(i, MappedAV);
+            Found = true;
+            break;
+          }
+        }
+      }
+      // If the value isn't already mapped into OutlinedHandlerFn, add it now
+      // and use the new value in the eh.actions call.
+      if (!Found) {
+        Value *NewVal = Materializer.materializeValueFor(V);
+        EHActions->setArgOperand(i, NewVal);
+      }
+    } else if (auto *HandlerArg = dyn_cast<Function>(V)) {
----------------
rnk wrote:
> Going forward, I would really like to change llvm.eh.actions to take an i32 frameescape index for the catch object instead. Doing this actually makes things easier for WinEHNumbering, which is where we build the try block map entries.
> 
> If we make this change first, you can remove this entire alloca case, because the index is the same in the parent function as in the outlined handler. Do you think it's worth defering this again, or would you rather try to get this in first and come back later?
If the changes to frameescape can be made quickly, I think it's best to have that in first.

http://reviews.llvm.org/D8596

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/