Revert r176154 in favor of a better approach.
authorBill Wendling <isanbard@gmail.com>
Fri, 8 Mar 2013 02:21:08 +0000 (02:21 +0000)
committerBill Wendling <isanbard@gmail.com>
Fri, 8 Mar 2013 02:21:08 +0000 (02:21 +0000)
commit2d915e2c150c00eee7441b6cc60480318277339d
treecf926b25db03401c749a2af45b0ddf1273a623c7
parentc4ffd66f0635b524daddcee5dc3378ed47104d8e
Revert r176154 in favor of a better approach.

Code generation makes some basic assumptions about the IR it's been given. In
particular, if there is only one 'invoke' in the function, then that invoke
won't be going away. However, with the advent of the `llvm.donothing' intrinsic,
those invokes may go away. If all of them go away, the landing pad no longer has
any users. This confuses the back-end, which asserts.

This happens with SjLj exceptions, because that's the model that modifies the IR
based on there being invokes, etc. in the function.

Remove any invokes of `llvm.donothing' during SjLj EH preparation. This will
give us a CFG that the back-end won't be confused about. If all of the invokes
in a function are removed, then the SjLj EH prepare pass won't insert the bogus
code the relies upon the invokes being there.
<rdar://problem/13228754&13316637>

llvm-svn: 176677
llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
llvm/lib/CodeGen/SjLjEHPrepare.cpp
llvm/test/CodeGen/ARM/invoke-donothing-assert.ll