[LLVMdev] RFC: Replace __cxa_begin_catch/__cxa_end_catch with intrinsics (original) (raw)

Kaylor, Andrew andrew.kaylor at intel.com
Mon Feb 2 17:39:08 PST 2015

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.

More information about the llvm-dev mailing list