[PATCH] Use WinEHPrepare to outline SEH finally blocks

Andy Kaylor andrew.kaylor at intel.com
Tue Mar 17 10:39:04 PDT 2015

Comment at: lib/CodeGen/WinEHPrepare.cpp:94
@@ -91,1 +93,3 @@
+  EHPersonality Personality;
   CatchHandlerMapTy CatchHandlerMap;
We should probably add comments to say which of these fields (I guess all of them currently) are reset with each Function the pass is run on.

Comment at: lib/CodeGen/WinEHPrepare.cpp:465
@@ +464,3 @@
+    // block.
+    LPadBB->replaceSuccessorsPhiUsesWith(NewLPadBB);
+    LPadBB->getTerminator()->eraseFromParent();
What exactly does this do?  I've seen some cases recently where cleanup outlining is choking because of PHINodes that are referring to the return value of the landingpad instruction.  This is too late to handle that (which just needs a few more VMap entries before outlining) but it raises the question in my mind of general handling of PHINodes which use values that are being erased from the original landing pads here.

I think that all of the code in question will be pruned as part of what we're doing here (it was resume blocks using either the landingpad value or values extracted from it).  I'm just raising the issue to see if you can think of anything else that might have a similar issue.

Comment at: lib/CodeGen/WinEHPrepare.cpp:474
@@ -447,3 +473,3 @@
       if (auto *CatchAction = dyn_cast<CatchHandler>(Action)) {
         ActionArgs.push_back(ConstantInt::get(Int32Type, 0));
This should be 1 according to your recent documentation.

Comment at: lib/CodeGen/WinEHPrepare.cpp:482
@@ -455,3 +481,3 @@
       } else {
         ActionArgs.push_back(ConstantInt::get(Int32Type, 1));
This should be 0.

Comment at: lib/CodeGen/WinEHPrepare.cpp:728
@@ +727,3 @@
+  Constant *Selector;
+  bool Res = isSelectorDispatch(StartBB, HandlerBB, Selector, NextBB);
+  (void)Res;
In the case of "__except(EXCEPTION_EXECUTE_HANDLER)" I'm seeing the landing pad branch unconditionally to the catch handler.



More information about the llvm-commits mailing list