[LLVMdev] New EH representation for MSVC compatibility

[Kaylor, Andrew]

> optimizing EH codepaths is not usually performance critical.
>> Leaving aside the rest of the thread, I feel the need to refute this point in isolation.  I've found that optimizing (usually simplifying and eliminating) exception paths ends up being *extremely* important for my workloads.  Failing to optimize exception paths sufficiently tends to indirectly hurt things like inlining for example.  Any design which starts with the assumption that optimizing exception paths isn't important is going to be extremely problematic for me.

That's interesting.

I wasn't thinking about performance so much as code size in my original comment.  I've been looking at IR recently where code from multiple exception handlers was combined while still maintaining the basic control flow of the EH code.  This kind of optimization is wreaking havoc for our current MSVC compatible EH implementation (hence the redesign), but I guess the Itanium ABI scheme doesn't have a problem with it.

I suppose that is closely related to your concerns about inlining, I just hadn't made the connection.

In theory the funclets should be able to share code blocks without any problem.  The entry and exit points are the critical parts that make them funclets.  I'm just not sure how we can get the optimization passes to recognize this fact while still meeting the MSVC runtime constraints.  Reid's proposal of separate catch blocks should help with that, but I'm still not sure we'll want to use this representation for targets that don't need it.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150518/f9a8cf6f/attachment.html>