[LLVMdev] New EH representation for MSVC compatibility

[Philip Reames]

On 05/18/2015 04:36 PM, Kaylor, Andrew wrote:
>
> >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.
>
Sorry for not responding here for so long.
>
> 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.
>
Since I'm pretty sure I added at least one optimization to simplify cfg 
which sounds problematic for you, sorry! :)
>
> I suppose that is closely related to your concerns about inlining, I 
> just hadn’t made the connection.
>
The effect on inlining is that combining the exception handler blocks 
reduces the perceived cost to inline a function with lots of exceptional 
control flow.  When you're coming from a language where *every* call is 
an invoke and you need some per function/frame code to recover/rethrow 
just about any exception (that's just an implementation detail), 
commoning exceptional control flow turns out to be rather important.

> 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.
>
If you fundamentally need the funclets, I think that makes you 
incompatible with the optimizations we want to support for itanium and 
related ABIs.  I have no problem with supporting both separately, though 
I am worried about how much maintenance burden that will create going 
forward.



Since I haven't been following the thread closely, is there an updated 
summary of the original proposal available?  I know that various parts I 
had concerns with (the unsplitable blocks for instance) got addressed, 
but I'm having trouble tracking all the changes in discussion.  Even 
just a quick list of "and we changed X" would be helpful.

Philip

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