search for: succ1

...n LLVM IR ("best" in the sense of allowing > other optimizations to run effectively)? Bear in mind that in this > example N=2, but it may be way bigger than that. Just to clarify: I already figured out two ways to do it, i.e.: %0 = phi i8* [blockaddr(%succ0), %pred0], [blockaddr(%succ1), %pred1], ... ... indirectbr %0, [%succ0, %succ1, ...] or %0 = phi i8 [0, %pred0], [1, %pred1], ... ... switch %0, undef, [0, %succ0], [1, %succ1], ... what I'd like to know is which one do you think is better (and why) or if there are better ways I didn't think of. -- Carlo Alberto...

...more regions. So, in this example: A { A(); ~A() throw(); }; void foo() throw() { A x; b(); } Your model has this as follows, modulo syntax: entry: %x = alloca %A invoke void @A::A(%A* %x) to label %succ0 unwind label %lp0 region 0 succ0: invoke void @b() to label %succ1 unwind label %lp1 region 0 succ1: call void @A::~A(%A* %x) nounwind ret void lp0: call void @A::~A(%A* %x) nounwind br label %lp1 lp1: dispatch region 0 [filter i8* null] # no resume edge Whereas my model has this as follows: entry: %x = alloca %A invoke void...

...; ~A() throw(); }; > void foo() throw() { > A x; > b(); > } > > Your model has this as follows, modulo syntax: > entry: > %x = alloca %A > invoke void @A::A(%A* %x) to label %succ0 unwind label %lp0 region 0 > succ0: > invoke void @b() to label %succ1 unwind label %lp1 region 0 > succ1: > call void @A::~A(%A* %x) nounwind > ret void > lp0: > call void @A::~A(%A* %x) nounwind > br label %lp1 > lp1: > dispatch region 0 [filter i8* null] # no resume edge > > Whereas my model has this as follows: &...

Nella citazione martedì 2 agosto 2011 20:02:08, Michael Ilseman ha scritto: > I'm assuming that you're talking about a situation where this can't be > determined statically in the existing LLVM IR, but you know it's true > and want to put it in (e.g. you're the one generating LLVM IR). Correct. Or, more precisely, I'd like to investigate macro compression, i.e.

...of them in BB_unique. B1 (declares PHI_1) B3 | | B2 | | | ExitBB1 ExitBB2 | Succ1 (uses PHI_1) becomes: B1 (declares PHI_1) B3 | | B2 | | | ExitBB1 ExitBB2...

On Nov 24, 2010, at 4:58 AM, John McCall wrote: >> If that's so, how do you encode which which landing pad is to be >> followed per region? >> >> Consider the following code: >> >> try { >> Foo f(); >> f.run(); // can throw exception >> Bar b(); >> b.run(); // can throw exception >> Baz z(); >> z.run(); // can throw

On Nov 24, 2010, at 2:59 AM, Renato Golin wrote: > If I got it right, the dispatch instruction will tell the > instructions/calls to unwind to specific landing pads (cleanup areas, > terminate), but the region number will encode try/catch areas, so that > all those cleanup landing pads should ultimately end up in the catch > area for that region. Caveat: I'm speaking from what

On Oct 11, 2010, at 9:05 AM, Xinfinity wrote: > > Hi, > > I am working on a pass aimed to unify multiple exits of a loop into a unique > basic block. The approach is straight forward: > I create a unique BasicBlock BB_unique that has as predecessors all the exit > blocks of the loop, it contains a phi instruction and a switch to redirect > the flow correctly.

...o() throw() { >> A x; >> b(); >> } >> >> Your model has this as follows, modulo syntax: >> entry: >> %x = alloca %A >> invoke void @A::A(%A* %x) to label %succ0 unwind label %lp0 region 0 >> succ0: >> invoke void @b() to label %succ1 unwind label %lp1 region 0 >> succ1: >> call void @A::~A(%A* %x) nounwind >> ret void >> lp0: >> call void @A::~A(%A* %x) nounwind >> br label %lp1 >> lp1: >> dispatch region 0 [filter i8* null] # no resume edge >> >> Whereas...

Hi, I am working on a pass aimed to unify multiple exits of a loop into a unique basic block. The approach is straight forward: I create a unique BasicBlock BB_unique that has as predecessors all the exit blocks of the loop, it contains a phi instruction and a switch to redirect the flow correctly. Additionally, for each initial exit block I create an associated block that will jump to the