[LLVMdev] New EH representation for MSVC compatibility
Philip Reames
listmail at philipreames.com
Wed Jun 17 18:18:04 PDT 2015
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>
More information about the llvm-dev
mailing list