search for: ehselector

Hello, Why does LLVM use __gcc_personality_v0 instead of __gxx_personality_v0 function when it lowers llvm.gcroot intrinsic? For my try-catch codegen I use last one (so does clang) and it conflicts with __gcc_personality_v0 produced by LLVM? I know how to solve it with my own GC plug-in, just wondering. And what's the difference between these two functions anyway? Thanks,

...} I'll have IR that looks more or less like this: ; Function Attrs: uwtable define void @_Z13do_some_thingRi(i32* dereferenceable(4) %i) #0 { entry: %i.addr = alloca i32*, align 8 %outer = alloca %class.Outer, align 1 %middle = alloca %class.Middle, align 1 %exn.slot = alloca i8* %ehselector.slot = alloca i32 %inner = alloca %class.Inner, align 1 %en = alloca i32, align 4 store i32* %i, i32** %i.addr, align 8 call void @_ZN5OuterC1Ev(%class.Outer* %outer) invoke void @_ZN6MiddleC1Ev(%class.Middle* %middle) to label %invoke.cont unwind label %lpad invoke.cont:...

...sonality i8* bitcast (i32 (...)* @__C_specific_handler to i8*) cleanup catch i8* bitcast (i32 (i8*, i8*)* @"\01?filt$0 at 0@foo@@" to i8*) %2 = extractvalue { i8*, i32 } %1, 0 store i8* %2, i8** %exn.slot %3 = extractvalue { i8*, i32 } %1, 1 store i32 %3, i32* %ehselector.slot store i8 1, i8* %abnormal.termination.slot br label %__finally __finally: ; preds = %lpad, %invoke.cont %0 = load i32, i32* %x, align 4 What I'm wondering is where exactly this models the call to @"\01?filt$0 at 0@foo@@" and its st...

> On Nov 18, 2014, at 11:07 AM, Reid Kleckner <rnk at google.com> wrote: > > On Tue, Nov 18, 2014 at 10:50 AM, Bob Wilson <bob.wilson at apple.com <mailto:bob.wilson at apple.com>> wrote: > >> On Nov 17, 2014, at 5:50 PM, Reid Kleckner <rnk at google.com <mailto:rnk at google.com>> wrote: >> >> On Mon, Nov 17, 2014 at 5:22 PM, Bob

...; preds = %if.end, %if.then %2 = landingpad { i8*, i32 } personality i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*) cleanup %3 = extractvalue { i8*, i32 } %2, 0 store i8* %3, i8** %exn.slot %4 = extractvalue { i8*, i32 } %2, 1 store i32 %4, i32* %ehselector.slot call void @"\01??1Bob@@QEAA at XZ"(%class.Bob* %bob) #3 ; Calling the destructor for a class named “Bob” br label %eh.resume Replacing __gxx_personality_v0 with the name of my custom personality function (which has the SEH signature) and scrubbing out the terminate and resume c...

These are exactly the sorts of code transformations we want to allow by delaying the outlining until later. By keeping such code inlined in the parent function until after optimization, we enable a lot of core optimizations like SROA. For example, we should be able to completely eliminate wrappers like unique_ptr that would otherwise stay around due to the pointer escaped to the destructor call

...%2 = landingpad { i8*, i32 } personality i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*) > > cleanup > > %3 = extractvalue { i8*, i32 } %2, 0 > > store i8* %3, i8** %exn.slot > > %4 = extractvalue { i8*, i32 } %2, 1 > > store i32 %4, i32* %ehselector.slot > > call void @"\01??1Bob@@QEAA at XZ"(%class.Bob* %bob) #3 ; Calling the destructor for a class named “Bob” > > br label %eh.resume > > > > Replacing __gxx_personality_v0 with the name of my custom personality function (which has the SEH signature)...

...i32 } personality i8* bitcast (i32 (...)* @__CxxFrameHandler3 to i8*) catch i8* bitcast (i8** @_ZTIi to i8*) catch i8* bitcast (i8** @_ZTIf to i8*) %5 = extractvalue { i8*, i32 } %4, 0 store i8* %5, i8** %exn.slot %6 = extractvalue { i8*, i32 } %4, 1 store i32 %6, i32* %ehselector.slot %2 = load i32* %a.addr, align 4 %3 = load i32* %b.addr, align 4 %add = add nsw i32 %2, %3 store i32 %add, i32* %x, align 4 br label %catch.dispatch <…snip…> } So in this scenario, even though the landingpad doesn’t have a cleanup clause, we’ll need to add one (better, the p...

Thanks for the additional information. Right now I’m experimenting with a mix of code compiled with MSVC and code compiled with clang, trying to get a C++ exception thrown and caught by the MSVC-compiled code across a function in the clang-compiled code. My goal here is to isolate a small part of what needs to be done in a way that lends itself to tinkering. I think this might lead me to the

...l __llvm__unsafe_stack_ptr +; LINUX-I386: .cfi_endproc + +; LINUX-X64: test18a: +; LINUX-X64-NOT: movq %fs:640 +; LINUX-X64: .cfi_endproc + +; DARWIN-X64: test18a: +; DARWIN-X64-NOT: movq ___llvm__unsafe_stack_ptr +; DARWIN-X64: .cfi_endproc + %a = alloca i32, align 4 + %exn.slot = alloca i8* + %ehselector.slot = alloca i32 + store i32 0, i32* %a, align 4 + invoke void @_Z3exceptPi(i32* %a) + to label %invoke.cont unwind label %lpad + +invoke.cont: + ret i32 0 + +lpad: + %0 = landingpad { i8*, i32 } personality i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*) + catch i8* nu...