search for: _ztif

...(i32 0) call void @llvm.eh.setehstate(i32 -1) call void @_Z10keep_goingv() ret void lpad: %eh.vals = landingpad { i8*, i32 } personality i8* bitcast (i32 (...)* @__CxxFrameHandler3 to i8*) cleanup catch i8* bitcast (i8** @_ZTIi to i8*) catch i8* bitcast (i8** @_ZTIf to i8*) %eh.ptrs = extractvalue { i8*, i32 } %eh.vals, 0 %eh.sel = extractvalue { i8*, i32 } %eh.vals, 1 br label %unwind.handlers unwind.handlers: %unwind.state = call i32 @llvm.eh.getunwindstate(%eh.ptrs) br label %unwind.dispatch unwind.dispatch: %4 = icmp eq i32 %unwind.state, i3...

...d ret void return: ; preds = %entry ret void } define void @_Z1cv() { entry: invoke void @_Z1bv() to label %return unwind label %"<L1>" personality @__gxx_personality_v0 catches %struct.__fundamental_type_info_pseudo* @_ZTIf "<L1>": ; preds = %entry %exc_ptr = tail call i8* @llvm.eh.exception() %filter = tail call i32 @llvm.eh.selector() %typeid = tail call i32 @llvm.eh.typeid.for(i8* bitcast (%struct.__fundamental_type_info_pseudo* @_ZTIf to i8*))...

On Dec 1, 2010, at 1:37 PM, Duncan Sands wrote: > Inlining > -------- > > Many a plausible seeming exception handling scheme has fallen by the way-side > because it interacts poorly with inlining. > > Here is how inlining would work with this scheme. It's pretty close to how > it works right now. Suppose you have > > invoke void @foo() > to

...; preds = %try.cont, %invoke.cont17 call void @_Z10keep_goingv() ret void lpad: ; preds = %try.cont, %entry %0 = landingpad { i8*, i32 } personality i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*) catch i8* bitcast (i8** @_ZTIf to i8*) %recover = call i8* (...)* @llvm.eh.actions( i32 1, i8* bitcast (i8** @_ZTIf to i8*), void (i8*, i8*)* @catch_float) indirectbr i8* %recover, [label %try.cont], [label %try.cont19] lpad1: ; preds = %invoke.cont4, %invoke.cont %3 = land...

...; preds = %invoke.cont2 %8 = landingpad { i8*, i32 } personality i8* bitcast (i32 (...)* @__CxxFrameHandler3 to i8*) cleanup at @_Z4testv.unwind.1 ; ~Inner catch i8* bitcast (i8** @_ZTIi to i8*) at @_Z4testv.catch.1 ; handle_int() catch i8* bitcast (i8** @_ZTIf to i8*) at @_Z4testv.catch.0 ; handle_float() The @_Z4testv.unwind.1 helper just calls ~Inner(), but not ~Outer. I think we'd need something more complex like this: lpad3: ; preds = %invoke.cont2 %8 = landingpad { i8*, i32 } personality i8* bitcas...

I am working on adding support for C++ exception handling when compiling for a native Windows target (that is a target with "MSVC" specified as the environment). Because of differences between how the native Windows runtime handles exceptions and the Itanium-based model used by current LLVM exception handling code, I believe this will require some extensions to the LLVM IR, though

Here is an alternative proposal to Bill's. It is closer to what we already have (which can be seen as a good or a bad thing!), and is also closer to what gcc does. It is more incremental than Bill's and introduces fewer new concepts. Executive summary ----------------- Remove the personality and list of catches out of eh.selector and stick them directly on invoke instructions. The

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

...) to label %invoke.cont unwind label %lpad lpad: ; preds = %entry %4 = landingpad { i8*, 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 %c...