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

Hi all,

I brought this up last week in an LLVMDev discussion of C++ EH support on
Windows, but I thought I should float it again with a subject that would be less
likely to be missed by people who don't have a direct interest in Windows
support.

I would like to introduce two new intrinsics, llvm.eh.begincatch and
llvm.eh.endcatch, to take the place of __cxa_begin_catch and __cxa_end_catch in
the IR prior to the CodeGen prepare passes.  For the majority of platforms the
intrinsics will be directly mapped to the existing function calls during one of
the CodeGen prepare passes.  For MSVC-environment Windows targets there is no
equivalent function call to be made, but these intrinsics will be extremely
useful during the WinEHPrepare pass as a means of identifying the limits of
catch-specific code.

If there is a reason why I should not introduce intrinsics for this purpose,
please give me feedback now.  Otherwise, I'm going to begin work on a patch
to support this in the back end with the expectation that a corresponding change
will be made in the clang front end when the intrinsic support is ready.

Thanks,
Andy

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150203/3ddfd094/attachment.html>

This seems reasonable to me. Adding John explicitly...

On Mon, Feb 2, 2015 at 4:03 PM, Kaylor, Andrew <andrew.kaylor at
intel.com>
wrote:
>  Hi all,
>
>
>
> I brought this up last week in an LLVMDev discussion of C++ EH support on
> Windows, but I thought I should float it again with a subject that would be
> less likely to be missed by people who don’t have a direct interest in
> Windows support.
>
>
>
> I would like to introduce two new intrinsics, llvm.eh.begincatch and
> llvm.eh.endcatch, to take the place of __cxa_begin_catch and
> __cxa_end_catch in the IR prior to the CodeGen prepare passes.  For the
> majority of platforms the intrinsics will be directly mapped to the
> existing function calls during one of the CodeGen prepare passes.  For
> MSVC-environment Windows targets there is no equivalent function call to be
> made, but these intrinsics will be extremely useful during the WinEHPrepare
> pass as a means of identifying the limits of catch-specific code.
>
>
>
> If there is a reason why I should not introduce intrinsics for this
> purpose, please give me feedback now.  Otherwise, I’m going to begin work
> on a patch to support this in the back end with the expectation that a
> corresponding change will be made in the clang front end when the intrinsic
> support is ready.
>
>
>
> Thanks,
>
> Andy
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150202/0d3efb77/attachment.html>

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