[PATCH] Add invoke of llvm.donothing to outlined catch and cleanup handlers to identify their personality

Andy Kaylor andrew.kaylor at intel.com
Tue Apr 7 12:15:30 PDT 2015


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.


REPOSITORY
  rL LLVM

http://reviews.llvm.org/D8835

Files:
  lib/CodeGen/WinEHPrepare.cpp

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: D8835.23360.patch
Type: text/x-patch
Size: 6242 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150407/c598590e/attachment.bin>


More information about the llvm-commits mailing list