[PATCH] D15962: [WinEH] Verify consistent funclet unwind exits

Joseph Tremoulet via llvm-commits llvm-commits at lists.llvm.org
Fri Jan 8 13:20:36 PST 2016


JosephTremoulet added a comment.

In http://reviews.llvm.org/D15962#321660, @majnemer wrote:

> Is there any way to get back the tests we lost in test/CodeGen/WinEH/wineh-no-demotion.ll ?  Those tests are nice because they stress instances where we might add another edge to a funclet (those tests show this by cloning an invoke).


Yes, looks like the tests can stay if I just remove the funclet bundles from the to-be-cloned invokes, so I've updated to do that.


================
Comment at: docs/ExceptionHandling.rst:837
@@ +836,2 @@
+destination other than caller; it is undefined behavior for such a ``call``
+or ``catchswitch`` to unwind.
----------------
Yes, you're understanding correctly.

When we have catchswitch A unwinding to pad B and we discover that pad B is immediately `unreachable`, to me it makes more sense to allow stomping out the edge and leaving catchswitch A as "unwinds to caller" like we do than it does to require that code to snoop around and see if catchswitch A has a parent pad and if an unwind edge which leaves the parent can be found and redirect catchswitch A to that edge's successor for consistency -- in addition to requiring a not-rocket-science but nonetheless nontrivial search for the parent's unwind successor, it also requires suddenly giving that successor a new predecessor and doing who-knows-what updates to maintain SSA etc in the face of that.

I absolutely agree that it would be nicer to have a nounwind variant of catchswitch, not just for this but also to be able to express catch-all over funclet EH in a way that the CFG reflects naturally.  I think it's a nontrivial undertaking (though easier now that we have parent tokens and funclet bundles than it would have been before), and not the top of my priority list.  Happy to review patches, though :).


http://reviews.llvm.org/D15962





More information about the llvm-commits mailing list