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
lgtm
lib/CodeGen/WinEHPrepare.cpp | ||
---|---|---|
770 | Do you think more work is necessary here? Unreachable seems like a reasonable thing to do. |
lib/CodeGen/WinEHPrepare.cpp | ||
---|---|---|
770 | No, that was a note to myself before I finished this function. Sorry about that. |
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. |
Do you think more work is necessary here? Unreachable seems like a reasonable thing to do.