N.B. This is with the new EH scheme:

The blocks with invokes have branches to the dispatch block, because that more
correctly models the behavior of the CFG. The dispatch of course has edges to
the landing pads. Those landing pads could contain invokes, which then have
branches back to the dispatch. This creates a loop. The machine LICM pass looks
at this loop and thinks it can hoist elements out of it. But because the
dispatch is an alternate entry point into the program, the hoisted instructions
won't be executed.

I wasn't able to get a testcase which was small and could reproduce all of the
time. The function_try_block.cpp in llvm-test was where this showed up.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141726 91177308-0d34-0410-b5e6-96231b3b80d8

diff --git a/lib/CodeGen/MachineLICM.cpp b/lib/CodeGen/MachineLICM.cpp
index f6a08d362080a8a9d7051209b0a4135eeeb193d5..70da9828e6750a3110dc6d05b002a154e9c7e1b3 100644 (file)
--- a/lib/CodeGen/MachineLICM.cpp
+++ b/lib/CodeGen/MachineLICM.cpp
@@ -336,6 +336,11 @@ bool MachineLICM::runOnMachineFunction(MachineFunction &MF) {
       continue;
     }
 
+    // If the header is a landing pad, then we don't want to hoist instructions
+    // out of it. This can happen with SjLj exception handling which has a
+    // dispatch table as the landing pad.
+    if (CurLoop->getHeader()->isLandingPad()) continue;
+
     if (!PreRegAlloc)
       HoistRegionPostRA();
     else {