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 f6a08d3..70da982 100644
--- a/lib/CodeGen/MachineLICM.cpp
+++ b/lib/CodeGen/MachineLICM.cpp
@@ -336,6 +336,11 @@
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 {
