2 Commits

Author	SHA1	Message	Date
Bill Wendling	e36b47e17b	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> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@176677 91177308-0d34-0410-b5e6-96231b3b80d8	2013-03-08 02:21:08 +00:00
Manman Ren	5e5974f51a	SelectionDAG: If llvm.donothing has a landingpad, we should clear ... CurrentCallSite to avoid an assertion failure: assert(MMI.getCurrentCallSite() == 0 && "Overlapping call sites!"); rdar://problem/13228754 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@176154 91177308-0d34-0410-b5e6-96231b3b80d8	2013-02-27 02:11:57 +00:00