2 Commits

Author	SHA1	Message	Date
Bill Wendling	8c7ceb2a0e	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	2013-03-08 02:21:08 +00:00
Manman Ren	894d0f9fc3	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 llvm-svn: 176154	2013-02-27 02:11:57 +00:00