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

1 files changed, 5 insertions, 0 deletions

diff --git a/lib/CodeGen/MachineLICM.cpp b/lib/CodeGen/MachineLICM.cpp
index f6a08d3620..70da9828e6 100644
--- 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 {