[LLVMdev] RFC: Replace __cxa_begin_catch/__cxa_end_catch with intrinsics

[Kaylor, Andrew]

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.