[cfe-dev] [LLVMdev] RFC: Replace __cxa_begin_catch/__cxa_end_catch with intrinsics

[Reid Kleckner]

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/cfe-dev/attachments/20150202/bde3e583/attachment.html>