llvm dev - Feb 2015 - [LLVMdev] RFC: Replace __cxa_begin_catch/__cxa_end_catch with intrinsics

> On Feb 2, 2015, at 4:53 PM, Reid Kleckner <rnk at google.com> wrote:
> This seems reasonable to me. Adding John explicitly…
Thanks, Reid.

Andy, I understand why Windows EH needs custom lowering here, and using
intrinsics seems like a fine approach, but I don’t understand why you’re
proposing changing the Itanium code generation pattern.  There’s no reason for
backends to have special knowledge of __cxa_begin_catch, and it’s actually not a
good idea for them to do so, because that’s unnecessarily language-specific and
personality-specific; even today, Objective-C EH implementations do use separate
personality and different begin/end catch functions.

If we ever decide to support a libUnwind personality function that relies on
function outlining — and I do have that as an eventual goal — it’ll probably
want a slightly different code-generation pattern anyway.  So write your code
generally where you can, but don’t worry about creating some sort of ultimate
unified backend EH lowering.

John.

Hi John,

Thanks for the feedback.

I'm fine not using the proposed intrinsics everywhere.  It just seemed to me
like a reasonable step since the back end is already taking a fair bit of action
based on the personality function.  Also, if I do introduce the intrinsics for
one target/personality function it seems like it may be a source of confusion
when other targets don't use them.  I suppose that is easily enough solved
with proper documentation though.  Perhaps I can even drop a "win" in
the name somewhere.

To be clear, are you OK with introducing these intrinsics for
WinEH+__CxxFrameHandler3 personality function use?

-Andy

-----Original Message-----
From: John McCall [mailto:rjmccall at apple.com] 
Sent: Monday, February 02, 2015 5:18 PM
To: Reid Kleckner
Cc: Kaylor, Andrew; LLVM Developers Mailing List; clang-dev Developers (cfe-dev
at cs.uiuc.edu)
Subject: Re: [LLVMdev] RFC: Replace __cxa_begin_catch/__cxa_end_catch with
intrinsics
> On Feb 2, 2015, at 4:53 PM, Reid Kleckner <rnk at google.com> wrote:
> This seems reasonable to me. Adding John explicitly…
Thanks, Reid.

Andy, I understand why Windows EH needs custom lowering here, and using
intrinsics seems like a fine approach, but I don’t understand why you’re
proposing changing the Itanium code generation pattern.  There’s no reason for
backends to have special knowledge of __cxa_begin_catch, and it’s actually not a
good idea for them to do so, because that’s unnecessarily language-specific and
personality-specific; even today, Objective-C EH implementations do use separate
personality and different begin/end catch functions.

If we ever decide to support a libUnwind personality function that relies on
function outlining — and I do have that as an eventual goal — it’ll probably
want a slightly different code-generation pattern anyway.  So write your code
generally where you can, but don’t worry about creating some sort of ultimate
unified backend EH lowering.

John.

I actually like the unified intrinsic approach here. The backend already
has to know things about the personality function. Until recently we would
assume that the personality function wants an Itanium LSDA, for example,
and dump that out into a target-specific section. Now on Windows we look at
the personality function and try to figure out what kind of preparation and
tables it wants.

It seems reasonable then that we could continue along the lines of
classifying some personalities as "Itanium" personalities and lowering
these new intrinsics out to __cxa_begin_catch / end_catch. We already do it
for resume -> _Unwind_Resume.

I think this is better than relying on the target to "know" what
wants,
which is what we have today with SjLj vs. CFI-driven EH. IMO it would be
cleaner if the backend knew that __g??_personality_sj0 meant it should run
the SjLjEHPrepare pass.

What do you think?

On Mon, Feb 2, 2015 at 5:17 PM, John McCall <rjmccall at apple.com> wrote:
> > On Feb 2, 2015, at 4:53 PM, Reid Kleckner <rnk at google.com>
wrote:
> > This seems reasonable to me. Adding John explicitly…
>
> Thanks, Reid.
>
> Andy, I understand why Windows EH needs custom lowering here, and using
> intrinsics seems like a fine approach, but I don’t understand why you’re
> proposing changing the Itanium code generation pattern.  There’s no reason
> for backends to have special knowledge of __cxa_begin_catch, and it’s
> actually not a good idea for them to do so, because that’s unnecessarily
> language-specific and personality-specific; even today, Objective-C EH
> implementations do use separate personality and different begin/end catch
> functions.
>
> If we ever decide to support a libUnwind personality function that relies
> on function outlining — and I do have that as an eventual goal — it’ll
> probably want a slightly different code-generation pattern anyway.  So
> write your code generally where you can, but don’t worry about creating
> some sort of ultimate unified backend EH lowering.
>
> John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150202/bde3e583/attachment.html>

> On Feb 2, 2015, at 6:04 PM, Reid Kleckner <rnk at google.com> wrote:
> I actually like the unified intrinsic approach here. The backend already
has to know things about the personality function. Until recently we would
assume that the personality function wants an Itanium LSDA, for example, and
dump that out into a target-specific section. Now on Windows we look at the
personality function and try to figure out what kind of preparation and tables
it wants.
> 
> It seems reasonable then that we could continue along the lines of
classifying some personalities as "Itanium" personalities and lowering
these new intrinsics out to __cxa_begin_catch / end_catch.
You are over-estimating how similar the code-generation patterns are going to be
here.  The information flow from the unwind mechanism to the catch clause can
differ quite wildly.

Go look at what happens in the different ABIs when an exception with a
non-trivial copy constructor is caught.  There’s an entire copy-construction
that’s explicit in Itanium but which I believe is done implicitly by the
personality equivalent in MSVC (necessarily, if you understand the purpose of
__cxa_begin_catch/__cxa_end_catch).

I agree that we should be more explicit about modeling the differences in
personality-mandated code generation.  Perhaps if we did this, people would stop
talking about the “Itanium LSDA” when they mean the gcc/g++ LSDA.  I just think
there is zero benefit in pretending that we can actually model every useful
difference between personalities with the name of the personality function.
> We already do it for resume -> _Unwind_Resume.
resume was specifically designed to be unwinder-agnostic.  This is why it takes
all the data from the landingpad even though _Unwind_Resume only needs the
exception pointer.

John.

> On Feb 2, 2015, at 5:39 PM, Kaylor, Andrew <andrew.kaylor at
intel.com> wrote:
> Hi John,
> 
> Thanks for the feedback.
> 
> I'm fine not using the proposed intrinsics everywhere.  It just seemed
to me like a reasonable step since the back end is already taking a fair bit of
action based on the personality function.  Also, if I do introduce the
intrinsics for one target/personality function it seems like it may be a source
of confusion when other targets don't use them.  I suppose that is easily
enough solved with proper documentation though.  Perhaps I can even drop a
"win" in the name somewhere.
Well, don’t make them deliberately unportable. :)  The g++ personality doesn’t
use subfunction extraction, but at some point I’d like to switch to a
personality which does, mostly in the interests of code size.  I would just
encourage you to design these intrinsics specifically around the problems of
personality-directed subfunction extraction, and understand that you’re going to
end up hardcoding a lot of Windows-specific behavior whether you mean to or not.
We can figure out how to make them more general when we have multiple
personalities that need subfunction extraction.
> To be clear, are you OK with introducing these intrinsics for
WinEH+__CxxFrameHandler3 personality function use?
Yes.

John.