search for: invcont

...; preds = %entry > br i1 undef, label %bb4, label %bb5 > > bb4: ; preds = %bb3 > unreachable > > bb5: ; preds = %bb3 > invoke void undef() > to label %invcont unwind label %lpad > > invcont: ; preds = %bb5 > %0 = invoke i8 @system__tasking__async_delays__enqueue_duration(i64 > undef, %struct.system__tasking__async_delays__delay_block* undef) > to label %bb8 unwind label %lpad ; &l...

...%entry >> br i1 undef, label %bb4, label %bb5 >> >> bb4: ; preds = %bb3 >> unreachable >> >> bb5: ; preds = %bb3 >> invoke void undef() >> to label %invcont unwind label %lpad >> >> invcont: ; preds = %bb5 >> %0 = invoke i8 @system__tasking__async_delays__enqueue_duration(i64 >> undef, %struct.system__tasking__async_delays__delay_block* undef) >> to label %bb8 unwind lab...

...ndef, label %bb4, label %bb5 >>> >>> bb4: ; preds = %bb3 >>> unreachable >>> >>> bb5: ; preds = %bb3 >>> invoke void undef() >>> to label %invcont unwind label %lpad >>> >>> invcont: ; preds = %bb5 >>> %0 = invoke i8 >>> @system__tasking__async_delays__enqueue_duration(i64 undef, >>> %struct.system__tasking__async_delays__delay_block* undef) >>&gt...

Hi Jakub, interesting patch. I ran it over the Ada testsuite and this picked up some problems even without enabling dse-ssu. For example, "opt -inline -dse -domtree" crashes on the attached testcase. Ciao, Duncan. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dom_crash.ll URL:

Hello, This patch adds non-local DSE optimization. It uses Static Single Use representation. This is my first "big" patch, please be tolerant :-) Please note that optimization is disabled by default. -Jakub -------------- next part -------------- A non-text attachment was scrubbed... Name: dse_ssu.patch Type: application/octet-stream Size: 17352 bytes Desc: not available URL:

...%1 = bitcast i8* %0 to i32* ; <i32*> [#uses=1] 50 store i32 78, i32* %1, align 4 51 invoke void @__cxa_throw(i8* %0, i8* bitcast (%struct.__fundamental_type_info_pseudo* @_ZTIi to i8*), void (i8*)* null) noreturn 52 to label %invcont unwind label %lpad 53 54 invcont: ; preds = %entry 55 unreachable 56 57 bb: ; preds = %lpad 58 %2 = tail call i8* @__cxa_begin_catch(i8* %eh_ptr) nounwind ; <i8*> [#uses=0] 59 %3 = invoke %"st...

HI all, here is a llvm IR : invoke void @__cxa_throw(i8* %7, i8* bitcast (%struct.__fundamental_type_info_pseudo* @_ZTIi to i8*), void (i8*)* null) noreturn to label %invcont unwind label %lpad say I want to get the Invoke's Operand's name, I use getOperand(i)->getName(), it can work for that the Operand hasname, but some Operand hasn't name, So, My problem is how can i get all the Operand 's name ? zhangzw

...did n't has name! zhangzw thanks 2009/3/26 Duncan Sands <baldrick at free.fr>: > Hi zhangzw, > >> invoke void @__cxa_throw(i8* %7, i8* bitcast >> (%struct.__fundamental_type_info_pseudo* @_ZTIi to i8*), void (i8*)* >> null) >> noreturn to label %invcont unwind label %lpad >> >> say I want to get the Invoke's Operand's name > > are you trying to get the name "@_ZTIi" or "@__cxa_throw"? > > Ciao, > > Duncan. >

Hi Bill, this proposal seems strangely complicated. I don't see the advantage of the dispatch instruction over just attaching the information to each invoke. Right now you have invoke void @_Z3foov() to label %invcont unwind label %catch.handlers catch.handlers: landingpad dispatch resume to label %... catches [ %struct.__fundamental_type_info_pseudo* @_ZTIi, label %ch.int %struct.__pointer_type_info_pseudo* @_ZTIPKc, label %ch.str ] catchall [i8* null, label % ch.ca] Why not comb...

...%1 = bitcast i8* %0 to i32* ; <i32*> [#uses=1] 12 store i32 34, i32* %1, align 4 13 invoke void @__cxa_throw(i8* %0, i8* bitcast (%struct.__fundamental_type_info_pseudo* @_ZTIi to i8*), void (i8*)* null) noreturn 14 to label %invcont unwind label %lpad 15 16 invcont: ; preds = %entry 17 unreachable 18 19 lpad: ; preds = %entry 20 %eh_ptr = tail call i8* @llvm.eh.exception() ; <i8*> [#uses=2] 21 %eh_select = tail call i32 (i8*, i8*, ...)* @l...

...Dec 1, 2010, at 10:20 AM, Duncan Sands wrote: > Hi Bill, this proposal seems strangely complicated. I don't see the advantage > of the dispatch instruction over just attaching the information to each invoke. > Right now you have > > invoke void @_Z3foov() > to label %invcont unwind label %catch.handlers > > catch.handlers: landingpad > dispatch resume to label %... > catches [ > %struct.__fundamental_type_info_pseudo* @_ZTIi, label %ch.int > %struct.__pointer_type_info_pseudo* @_ZTIPKc, label %ch.str > ] > catchall [i8*...

...onstant %struct.__fundamental_type_info_pseudo @_ZTIPKc = external constant %struct.__pointer_type_info_pseudo define void @_Z3barv() optsize ssp { entry: %a = alloca %struct.A, align 8 %b = alloca %struct.B, align 8 %c = alloca %struct.C, align 8 invoke void @_Z3foov() to label %invcont unwind label %catch.handlers invcont: invoke void @_Z3foov() to label %invcont1 unwind label %a.dtor invcont1: invoke void @_Z3foov() to label %invcont2 unwind label %b.dtor invcont2: invoke void @_Z3foov() to label %bb1 unwind label %c.dtor bb1: invoke voi...

Hi Bill, there are a couple of things I didn't understand about your proposal, for example how it interacts with inlining, whether it is feasible to do the "turn invoke-of-Unwind_Resume into a branch" optimization and also whether in "resumedest" you still plan to use _Unwind_Resume to continue unwinding up the stack. Could you please show what the LLVM IR would look like

Hi zhangzw, > invoke void @__cxa_throw(i8* %7, i8* bitcast > (%struct.__fundamental_type_info_pseudo* @_ZTIi to i8*), void (i8*)* > null) > noreturn to label %invcont unwind label %lpad > > say I want to get the Invoke's Operand's name are you trying to get the name "@_ZTIi" or "@__cxa_throw"? Ciao, Duncan.

Hi zhangzw, >> invoke void @__cxa_throw(i8* %7, i8* bitcast >> (%struct.__fundamental_type_info_pseudo* @_ZTIi to i8*), void (i8*)* >> null) >> noreturn to label %invcont unwind label %lpad > > >>are you trying to get the name "@_ZTIi" or "@__cxa_throw"? > > yes! i want get the name @_ZTi or @__cxa_throw, > the latter @__cxa_throw i can get it throw value->getName(), but the > @_ZTi it did n't has name! if II...

Hi Bill, >> Why not combine this into: >> >> invoke void @_Z3foov() >> to label %invcont unwind resume to label %... >> catches [ >> %struct.__fundamental_type_info_pseudo* @_ZTIi, label %ch.int >> %struct.__pointer_type_info_pseudo* @_ZTIPKc, label %ch.str >> ] >> catchall [i8* null, label % ch.ca <http://ch.ca>] >> >> ? That would get r...

...ry { if (j > 50) throw 100; } catch (int status) { j++; } return j; } This produces the CFG shown in the attachment, which appears to have 3 exit blocks. At least, there are 3 blocks with no successors. (I don't yet understand the semantics of the "invcont" and "Unwind" blocks, so perhaps I'm misunderstanding something here.) Anyway, given this code, how would one identify the "real" exit block (the one labeled "return")? Obviously I can't just search for the block without successors because there are...

...e number 0). A > possible syntax: > > <catch info> = [personality <ptr>] [cleanup] [catches <list of catches and filters>] > > Here's an example where there is no cleanup and there are two handlers: > > invoke void @_Z3foov() > to label %invcont unwind label %catch.handlers personality > @__gxx_personality_v0 catches %struct.__fundamental_type_info_pseudo* @_ZTIi, > %struct.__pointer_type_info_pseudo* @_ZTIPKc > > Note that unlike in Bill's proposal there isn't a label for each catch > object, just one global labe...

...cleanup (in eh.selector the flag is the number 0). A possible syntax: <catch info> = [personality <ptr>] [cleanup] [catches <list of catches and filters>] Here's an example where there is no cleanup and there are two handlers: invoke void @_Z3foov() to label %invcont unwind label %catch.handlers personality @__gxx_personality_v0 catches %struct.__fundamental_type_info_pseudo* @_ZTIi, %struct.__pointer_type_info_pseudo* @_ZTIPKc Note that unlike in Bill's proposal there isn't a label for each catch object, just one global label (the existing unwind la...

...cheme 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 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 o...