This is an archive of the discontinued LLVM Phabricator instance.

Add invoke of llvm.donothing to outlined catch and cleanup handlers to identify their personality
ClosedPublic

Authored by andrew.w.kaylor on Apr 5 2015, 3:23 PM.

Details

Reviewers
majnemer
rnk
Summary

This is a patch we talked about Friday on IRC to make it easier to identify the personality function associated with a catch or cleanup handler that has been outlined for native Windows exception handling.

Diff Detail

Repository
rL LLVM

Event Timeline

andrew.w.kaylor retitled this revision from to Add invoke of llvm.donothing to outlined catch and cleanup handlers to identify their personality.
andrew.w.kaylor updated this object.
andrew.w.kaylor edited the test plan for this revision. (Show Details)
andrew.w.kaylor added reviewers: majnemer, rnk.
andrew.w.kaylor set the repository for this revision to rL LLVM.
andrew.w.kaylor added a subscriber: Unknown Object (MLST).
rnk accepted this revision.Apr 6 2015, 1:42 PM
rnk edited edge metadata.

lgtm

lib/CodeGen/WinEHPrepare.cpp
770

Do you think more work is necessary here? Unreachable seems like a reasonable thing to do.

This revision is now accepted and ready to land.Apr 6 2015, 1:42 PM
lib/CodeGen/WinEHPrepare.cpp
770

No, that was a note to myself before I finished this function. Sorry about that.

andrew.w.kaylor edited edge metadata.

The only changes from the previously reviewed version are that I merged with top of trunk and I revised the WinEHCleanupDirector::handleEndCatch implementation.

After merging with trunk the cppeh-alloca-sink.ll test was asserting with this patch.

The problem is that nested "cleanup" handlers were being populated with an unreachable instruction because they begin with a call to llvm.eh.endcatch. In earlier tests I had been manually editing the IR to change invokes with effectively empty unwind destinations to calls, but this problem will continue to show up because the front end is still generating code like this. Also, I think we would have incorrectly handled nested cleanup of non-empty landing pads.

I believe that the cleanup cloning code will never find calls to llvm.eh.endcatch that aren't part of nested landing pads because it stops cloning when it sees llvm.eh.begincatch and doesn't follow that block's children.

I expect that there will be problems if a catch-all handler requires cleanup and both the cleanup and the catch handler are in the same block. This is not a new problem, so I just added a FIXME comment to note it.

lib/CodeGen/WinEHPrepare.cpp
1211

After thinking about this a little more, I think this comment is misplaced. I believe the cleanup code will always precede the catch code if they are in the same block, and the cleanup handler will stop cloning when it sees eh.begincatch. The cleanup code may be duplicated in the catch handler.

In any event, I'm going to delete this FIXME comment and see if I can create a test case.

This was implemented in r234360.