[LLVMdev] New EH representation for MSVC compatibility

[Reid Kleckner]

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>