llvm dev - Jun 2015 - [LLVMdev] New EH representation for MSVC compatibility

> 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>

On Mon, May 18, 2015 at 4:36 PM, Kaylor, Andrew <andrew.kaylor at
intel.com>
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.
>
On the whole, the whole reason we've gone down this path is to support
stronger analysis of EH paths, but I always think about it in terms of
supporting simplification of the normal control flow path. Consider
unique_ptr:

void f() {
  std::unique_ptr<int> p(new int(42));
  g(p.get());
}

This representation should support removing the heap allocation here by
inlining the destructor on the normal path and EH path and promoting the
heap allocation to a stack allocation. If our representation required early
outlining, this would not be possible, or at least it would require
inter-procedural analysis.

 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.
>
I think sharing code between funclets would require some extreme gymnastics
to generate the right pdata and xdata, but I suppose it's not too different
from what MSVC 2015 requires for coroutines.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150518/26c3b8b3/attachment.html>

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>

On Wed, Jun 17, 2015 at 6:18 PM, Philip Reames <listmail at
philipreames.com>
wrote:
> 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.
>
We should do an updated summary, but I've been busy.

We really do need to keep the unsplittable catchblocks, though.
Fundamentally, what we have is control flow described by data. This
proposal essentially adds LLVM instructions that model that data. We can't
insert real instructions like loads and stores between EH dispatch table
entries, so it's forbidden.

We can compensate for all the other CFG merging operations after the fact
by duplicating code, but it's really hard to pattern match back EH dispatch
once it's been allowed to round trip through memory, phis, GVN, etc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150618/b4682288/attachment.html>