RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-10-21 03:53:04 +02:00
Code Issues Projects Releases Wiki Activity

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

Browse Source 
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.

llvm-svn: 141726
This commit is contained in:
Bill Wendling 2011-10-11 22:42:31 +00:00
parent 8a43300a4f
commit f8cd4fcba7
1 changed files with 5 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
lib/CodeGen/MachineLICM.cpp
View File

@ -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 {