This is an archive of the discontinued LLVM Phabricator instance.

[WinEH] Add cleanupendpad instruction
ClosedPublic

Authored by JosephTremoulet on Aug 28 2015, 8:42 AM.

Details

Summary

Add a cleanupendpad instruction, used to mark exceptional exits out of
cleanups (for languages/targets that can abort a cleanup with another
exception). The cleanupendpad instruction is similar to the catchendpad
instruction in that it is an EH pad which is the target of unwind edges in
the handler and which itself has an unwind edge to the next EH action.
The cleanupendpad instruction, similar to cleanupret has a cleanuppad
argument indicating which cleanup it exits. The unwind successors of a
cleanuppad's cleanupendpads must agree with each other and with its
cleanuprets.

Update WinEHPrepare (and docs/tests) to accomodate cleanupendpad.

Diff Detail

Event Timeline

JosephTremoulet retitled this revision from to [WinEH] Add cleanupendpad instruction.
JosephTremoulet updated this object.
JosephTremoulet added a subscriber: llvm-commits.
JosephTremoulet added inline comments.
lib/CodeGen/WinEHPrepare.cpp
3308–3313

This part is likely wrong or incomplete; I have some questions about how to proceed that I felt were best asked in the context of a code review:

  1. As written, this will leave an unreachable as the first instruction in a block that's the target of unwind edges, which doesn't verify. I can see that if we were to run SimplifyCFGOpt::SimplifyUnreachable on it, it would rewrite any invoke predecessors as calls. Does that mean we need to run SimplifyCFGOpt on the function?
  2. Should SimplifyCFGOpt::SimplifyUnreachable be extended to rewrite catchendpad/cleanupendpad/terminatepad/cleanupret predecessors as 'unwind to caller'? Does it matter that doing so would make those predecessors 'mayThrow()' where they weren't before? From the comment "This would be a good place to note that the call does not throw though" in SimplifyUnreachable, I'm guessing the same happens for the invoke->call rewrite so it's ok (or at least won't make things worse), but not sure I'm intepreting that correctly.
  3. I think we'll need to do something similar for unwind edges that target implausible catchendpads, but since the plausiblity check there is 'is this catchendpad in the parent funclet', I think that will need to happen after the treeifying duplication that makes "*the* parent funclet" well-defined. [I guess this one was a comment, not a question.]
  • rebase
  • update mergefunc test (changing the numeric opcode values changed its output order)
JosephTremoulet added inline comments.Sep 1 2015, 5:09 PM
lib/CodeGen/WinEHPrepare.cpp
3308–3314

Seems like the right thing to do here will be to share the utility discussed in D12434

majnemer accepted this revision.Sep 2 2015, 1:46 PM
majnemer edited edge metadata.

This LGTM modulo the change to "Remove implausible terminators and replace them with UnreachableInst". I think that the right thing to do there is, as mentioned, to update the cleanupendpad's predecessor to unwind to caller.

This revision is now accepted and ready to land.Sep 2 2015, 1:46 PM