transform. I.e., if a clean-up eh.selector call dominates the invoke of an
_Unwind_Resume_or_Rethrow, then we convert the eh.selector into a
catch-all. This patch, however, uses the DominatorTree information, and doesn't
go through the whole rigmarole of starting at the eh.exception call, finding the
corresponding URoR and eh.selector calls, and trying to trace through any number
of instruction types to get to them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99846 91177308-0d34-0410-b5e6-96231b3b80d8
'invoke' instruction. You will get a situation like this:
bb:
%ehptr = eh.exception()
%sel = eh.selector(%ehptr, @per, 0);
...
bb2:
invoke _Unwind_Resume_or_Rethrow(%ehptr) %normal unwind to %lpad
lpad:
...
The unwinder will see the %sel call as a clean-up and, if it doesn't have a
catch further up the call stack, it will skip running it. But there *is* another
catch up the stack -- the catch for the %lpad. However, we can't see that. This
is fixed in code-gen, where we detect this situation, and convert the "clean-up"
selector call into a "catch-all" selector call. This gives us the correct
semantics.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99671 91177308-0d34-0410-b5e6-96231b3b80d8
--- Reverse-merging r85338 into '.':
U lib/CodeGen/SimpleRegisterCoalescing.cpp
U lib/CodeGen/SimpleRegisterCoalescing.h
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85454 91177308-0d34-0410-b5e6-96231b3b80d8
Chris claims we should never have visibility_hidden inside any .cpp file but
that's still not true even after this commit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85042 91177308-0d34-0410-b5e6-96231b3b80d8
created once, so shouldn't be stuck in the middle of the loop. Also early exit
if there are no uses of UnwindInst in the function.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81785 91177308-0d34-0410-b5e6-96231b3b80d8
code in preparation for code generation. The main thing it does
is handle the case when eh.exception calls (and, in a future
patch, eh.selector calls) are far away from landing pads. Right
now in practice you only find eh.exception calls close to landing
pads: either in a landing pad (the common case) or in a landing
pad successor, due to loop passes shifting them about. However
future exception handling improvements will result in calls far
from landing pads:
(1) Inlining of rewinds. Consider the following case:
In function @f:
...
invoke @g to label %normal unwind label %unwinds
...
unwinds:
%ex = call i8* @llvm.eh.exception()
...
In function @g:
...
invoke @something to label %continue unwind label %handler
...
handler:
%ex = call i8* @llvm.eh.exception()
... perform cleanups ...
"rethrow exception"
Now inline @g into @f. Currently this is turned into:
In function @f:
...
invoke @something to label %continue unwind label %handler
...
handler:
%ex = call i8* @llvm.eh.exception()
... perform cleanups ...
invoke "rethrow exception" to label %normal unwind label %unwinds
unwinds:
%ex = call i8* @llvm.eh.exception()
...
However we would like to simplify invoke of "rethrow exception" into
a branch to the %unwinds label. Then %unwinds is no longer a landing
pad, and the eh.exception call there is then far away from any landing
pads.
(2) Using the unwind instruction for cleanups.
It would be nice to have codegen handle the following case:
invoke @something to label %continue unwind label %run_cleanups
...
handler:
... perform cleanups ...
unwind
This requires turning "unwind" into a library call, which
necessarily takes a pointer to the exception as an argument
(this patch also does this unwind lowering). But that means
you are using eh.exception again far from a landing pad.
(3) Bugpoint simplifications. When bugpoint is simplifying
exception handling code it often generates eh.exception calls
far from a landing pad, which then causes codegen to assert.
Bugpoint then latches on to this assertion and loses sight
of the original problem.
Note that it is currently rare for this pass to actually do
anything. And in fact it normally shouldn't do anything at
all given the code coming out of llvm-gcc! But it does fire
a few times in the testsuite. As far as I can see this is
almost always due to the LoopStrengthReduce codegen pass
introducing pointless loop preheader blocks which are landing
pads and only contain a branch to another block. This other
block contains an eh.exception call. So probably by tweaking
LoopStrengthReduce a bit this can be avoided.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72276 91177308-0d34-0410-b5e6-96231b3b80d8
