search for: lpad2

.....)* @llvm.eh.selector.i32( i8* %eh_ptr, i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*)) tail call i32 (...)* @_Unwind_Resume( i8* %eh_ptr ) unreachable ... } define i32 @main() { entry: invoke void @_Z1fv( ) to label %somewhere2 unwind label %lpad2 ... lpad2: ; preds = %entry %eh_ptr = tail call i8* @llvm.eh.exception( ) %eh_select14 = tail call i32 (i8*, i8*, ...)* @llvm.eh.selector.i32( i8* %eh_ptr, i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*), i8* null ) print_a_message_and_exit ... } And this works fin...

(Mail system seems to have eaten this, sorry if it's a repeat) On Dec 8, 2007, at 12:48 AM, Duncan Sands wrote: > Hi Dale, > >> - Why was C++ claiming that every selector has a catch-all handler? > > this is easy: because the semantics of invoke require it. Yes, > really. > If unwinding reaches an invoke then control is required to jump to the > unwind basic

...ppen. If we follow the branch to “normal.cont2” it could conceivably take us through the entire CFG for the function. Obviously we want to avoid that. 2) A block shared between unconnected landing pads lpad1: landingpad … cleanup catch <some type> … … br label %shared.block lpad2: landingpad … cleanup catch <some other type> … … br label %shared.block shared.block: %dst = phi i1 [1, %lpad1], [0, %lpad2] ; do something that happens in both cleanup handlers … br i1 %dst, label %lpad1.catch.dispatch, label %lpad2.catch.dispatch lpad1.catch.dispatc...

...8*)) I wasn't advocating this; agree it is wrong. > tail call i32 (...)* @_Unwind_Resume( i8* %eh_ptr ) > unreachable > ... > } > > define i32 @main() { > entry: > invoke void @_Z1fv( ) > to label %somewhere2 unwind label %lpad2 > ... > lpad2: ; preds = %entry > %eh_ptr = tail call i8* @llvm.eh.exception( ) > %eh_select14 = tail call i32 (i8*, i8*, ...)* > @llvm.eh.selector.i32( i8* %eh_ptr, i8* bitcast (i32 (...)* > @__gxx_personality_v0 to i8*), i8* null ) > print_a_messa...

...you have >> >> invoke void @foo() >> to label %invcont unwind label %lpad<foo catch info> >> >> and you want to inline foo. Suppose foo contains an invoke: >> >> invoke void @bar() >> to label %invcont2 unwind label %lpad2<bar catch info> >> >> Then after inlining you have an invoke of bar in which foo's catch info >> has been appended to bar's: >> >> invoke void @bar() >> to label %invcont2 unwind label %lpad2<joined catch info> >> >>...

...t; it works right now. Suppose you have > > invoke void @foo() > to label %invcont unwind label %lpad <foo catch info> > > and you want to inline foo. Suppose foo contains an invoke: > > invoke void @bar() > to label %invcont2 unwind label %lpad2 <bar catch info> > > Then after inlining you have an invoke of bar in which foo's catch info > has been appended to bar's: > > invoke void @bar() > to label %invcont2 unwind label %lpad2 <joined catch info> > > What does appending <foo c...

...> invoke void @foo() >>> to label %invcont unwind label %lpad<foo catch info> >>> >>> and you want to inline foo. Suppose foo contains an invoke: >>> >>> invoke void @bar() >>> to label %invcont2 unwind label %lpad2<bar catch info> >>> >>> Then after inlining you have an invoke of bar in which foo's catch info >>> has been appended to bar's: >>> >>> invoke void @bar() >>> to label %invcont2 unwind label %lpad2<joined catch inf...

(Moving this discussion on list as this could be of general interest.) My current work-in-progress implementation is attempting to map out the blocks used by a landing pad before it starts outlining. It creates a table of catch and cleanup handlers with the block at which each one starts. During outlining I intend to have another mechanism to check to see if we’ve already outlined the handler

...personality @__gxx_personality_v0 catches %struct.__fundamental_type_info_pseudo* @_ZTIi, %struct.__pointer_type_info_pseudo* @_ZTIPKc, i8* null "3": ; preds = %entry invoke void @_Z3foov() to label %"4" unwind label %lpad25 personality @__gxx_personality_v0 catches %struct.__fundamental_type_info_pseudo* @_ZTIi, %struct.__pointer_type_info_pseudo* @_ZTIPKc, i8* null "4": ; preds = %"3" invoke void @_Z3foov() to label %"5" unwi...

Hi Reid, Is this design supposed to be able to cope with asynchronous exceptions? I am having trouble imagining how this would work without adding the ability to associate landing pads with scopes in LLVM IR. Vadim On Tue, Nov 25, 2014 at 5:27 PM, Reid Kleckner <rnk at google.com> wrote: > On Tue, Nov 25, 2014 at 3:09 PM, Kaylor, Andrew <andrew.kaylor at intel.com> > wrote:

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

...we could make these changes, but once we do that it's not clear to me that we should be using the same landing pad instruction anymore. Even if we did make these changes, we'll have landing pads like: invoke @do_inner_thing() ... unwind label %lpad1 invoke @~Inner() ... unwind label %lpad2 invoke @~Outer() ... unwind label %lpad3 lpad1: landingpad ... cleanup at ~Inner catch @"typeinfo for int" at @handle_int cleanup at ~Outer catch @"typeinfo for float" at @handle_float lpad2: landingpad ... catch @"typeinfo for int" at @handl...

...t; it works right now. Suppose you have > > invoke void @foo() > to label %invcont unwind label %lpad <foo catch info> > > and you want to inline foo. Suppose foo contains an invoke: > > invoke void @bar() > to label %invcont2 unwind label %lpad2 <bar catch info> > > Then after inlining you have an invoke of bar in which foo's catch info > has been appended to bar's: > > invoke void @bar() > to label %invcont2 unwind label %lpad2 <joined catch info> > > What does appending <foo c...

...i32* > ... > > mybb: unwind to label %lpad1 > %x = load i32* %xp ; edge to lpad1 here > store i32 0, i32* %xp ; edge to lpad1 here > call void @f() ; edge to lpad1 here > br label %mybb2 ; cannot remove branch due to differing lpads > > mybb2: unwind to label %lpad2 > ... > > lpad: > %xx = load i32* %xp ; we cannot make %xx a phi between %x and 0 due to > implicit control flow. Maybe we could split mybb and then make the phi, > but, ew. > > This is a mountain. I think you can climb it, but I'm *not* signing up for > it. :) Ad...