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

[Reid Kleckner]

This seems pretty close to done. Sorry for the delay, I was staring at .xdata tables all day long. =P


REPOSITORY
  rL LLVM

================
Comment at: lib/CodeGen/WinEHPrepare.cpp:105-124
@@ -100,1 +104,22 @@
+
+  // This maps landing pad instructions found in outlined handlers to
+  // the landing pad instruction in the parent function from which they
+  // were cloned.  The cloned/nested landing pad is used as the key
+  // because the landing pad may be cloned into multiple handlers.
+  // This map will be used to add the llvm.eh.actions call to the nested
+  // landing pads after all handlers have been outlined.
+  DenseMap<LandingPadInst *, const LandingPadInst *> NestedLPtoOriginalLP;
+
+  // This maps blocks in the parent function which are destinations of
+  // catch handlers to cloned blocks in (other) outlined handlers. This
+  // handles the case where a nested landing pads has a catch handler that
+  // returns to a handler function rather than the parent function.
+  // The original block is used as the key here because there should only
+  // ever be one handler function from which the cloned block is not pruned.
+  // The original block will be pruned from the parent function after all
+  // handlers have been outlined.  This map will be used to adjust the
+  // return instructions of handlers which return to the block that was
+  // outlined into a handler.  This is done after all handlers have been
+  // outlined but before the outlined code is pruned from the parent function.
+  DenseMap<const BasicBlock *, BasicBlock *> LPadTargetBlocks;
 };
----------------
Thanks, these comments help. :)

================
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);
----------------
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.

================
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)) {
----------------
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?

http://reviews.llvm.org/D8596

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