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

Reid Kleckner rnk at google.com
Tue Feb 3 09:56:41 PST 2015


On Mon, Feb 2, 2015 at 7:05 PM, John McCall <rjmccall at apple.com> wrote:

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

Makes sense. LLVM shouldn't be too heroic about papering over the
differences.

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.


I guess that was my misunderstanding and I'm guilty of promoting that
terminology. :) The document leads one to believe that the tables are
covered later, but now that I look again, I see there is very little
information.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150203/794ed7df/attachment.html>


More information about the cfe-dev mailing list