If we mark clean-ups as clean-ups, then it could break when inlining through an
authorBill Wendling <isanbard@gmail.com>
Fri, 26 Mar 2010 23:41:30 +0000 (23:41 +0000)
committerBill Wendling <isanbard@gmail.com>
Fri, 26 Mar 2010 23:41:30 +0000 (23:41 +0000)
commit2ad4aca8b2924065dfe51113ff197026a9c762c2
tree399c92c0420b4d8532e897c429183e5b953b5395
parent629c25cda6af43c16ee4d1ef2301c9ff1531d041
If we mark clean-ups as clean-ups, then it could break when inlining through an
'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
lib/CodeGen/DwarfEHPrepare.cpp