similar to: [LLVMdev] unwinds to in the CFG

On Mar 27, 2008, at 11:15 PM, Nick Lewycky wrote: > I have a new plan for handling 'unwinds to' in the control flow graph > and dominance. > > Just as a quick recap the problem I encountered is how to deal > instructions in a block being used as operands in the unwind dest. > Such > as this: > > bb1: unwinds to %cleanup > call void @foo() ; might throw,

I have a new plan for handling 'unwinds to' in the control flow graph and dominance. Just as a quick recap the problem I encountered is how to deal instructions in a block being used as operands in the unwind dest. Such as this: bb1: unwinds to %cleanup call void @foo() ; might throw, might not %x = add i32 %y, %z call void @foo() ; might throw, might not ret void cleanup:

Hi Nick, > Just as a quick recap the problem I encountered is how to deal > instructions in a block being used as operands in the unwind dest. Such > as this: > > bb1: unwinds to %cleanup > call void @foo() ; might throw, might not > %x = add i32 %y, %z > call void @foo() ; might throw, might not > ret void > cleanup: > call void @use(i32 %x)

I'm chasing a wrong-codegen bug that looks very much like this, except that I do not have a second call to foo; I have %x being referenced in the unwinding code, where it hasn't been set. Was there a resolution for this? On Apr 3, 2008, at 10:58 AM, Duncan Sands wrote: > Hi Devang, >>> Just as a quick recap the problem I encountered is how to deal >>>

Hi Devang, > > Just as a quick recap the problem I encountered is how to deal > > instructions in a block being used as operands in the unwind dest. > > Such > > as this: > > > > bb1: unwinds to %cleanup > > call void @foo() ; might throw, might not > > %x = add i32 %y, %z > > call void @foo() ; might throw, might not > > ret

> In LLVM the rule is that an instruction must be dominated by its > operands. ... > We already have this issue with invoke. Consider: > > bb1: > %x = invoke i32 @f() to label %normal unwind label %unwind > normal: > phi i32 [%x, %bb1] > ret i32 %x > unwind: > phi i32 [%x, %bb1] ; illegal > ret i32 %x > > The PHI in %unwind must mention

On 2008-03-29, at 00:57, Nick Lewycky wrote: > Gordon Henriksen wrote: > >> What blocks would a phi node in %catch require for a case like this? >> >> define i8 @f(i1 %b) { >> entry: >> b label %try >> try: unwinds to %catch >> b i1 %b, label %then, label %else >> then: unwinds to %catch >> ret void >>

Gordon Henriksen wrote: > On 2008-03-29, at 00:57, Nick Lewycky wrote: > >> Gordon Henriksen wrote: >> >>> What blocks would a phi node in %catch require for a case like this? >>> >>> define i8 @f(i1 %b) { >>> entry: >>> b label %try >>> try: unwinds to %catch >>> b i1 %b, label %then, label %else

Gordon Henriksen wrote: > What blocks would a phi node in %catch require for a case like this? > > define i8 @f(i1 %b) { > > entry: > > b label %try > > try: unwinds to %catch > > b i1 %b, label %then, label %else > > then: unwinds to %catch > > ret void > > else: unwinds to %catch > > ret

Hi Nick, On Mar 28, 2008, at 02:15, Nick Lewycky wrote: > Before I start investing time implementing these changes, does > anyone foresee any problems that I missed? Stepping back from the nuts and bolts for a moment, could you precisely define what constitutes a predecessor in this model? What blocks would a phi node in %catch require for a case like this? define i8 @f(i1 %b) {

Sorry -- Small change. Nick Lewycky wrote: > A. redefine the CFG a bit. > i. pred_iterator stays the same. pred_iterator becomes an inverse of outedge_iterator. That is, edges that lead to the execution of this block, regardless of whether it's an unwind-edge or not. Nick

I have what appears to be a bug in LLVM... I'm deeply hesitant to label it a bug, given my lack of experience with LLVM, but the behaviour of this fragment strongly suggests a bug. In particular, compiling and running this fragment using a fresh SVN build yields this stderr: uccello:/tmp clements$ lli a.out.bc 0 lli 0x005e72b6 char const* std::find<char const*,

From what I understand, the unwind instruction is implemented only for the interpreter: there is a -lowerunwind pass for compiling to other systems which will either lower unwind and invoke to setjmp/ longjmp (slow) or turn invokes into calls and unwinds into abort()s. On 26 Dec 2008, at 15:19, Matt Giuca wrote: > > > Jon Harrop wrote: >> >> Is it? I was just reading

Marc de Kruijf wrote: > > Can anyone tell me if invoke/unwind is stable in 2.3? I'm seeing some > really weird stuff -- unwinds are ending up in seemingly arbitrary > places... > definitely not inside the caller's unwind block My target is x86. > > As a simple test, I tried to compile the following code and I got a > segmentation fault. It looks good to me.

Alastair Lynn wrote: > > From what I understand, the unwind instruction is implemented only > for the interpreter: there is a -lowerunwind pass for compiling to > other systems which will either lower unwind and invoke to setjmp/ > longjmp (slow) or turn invokes into calls and unwinds into abort()s. > Ah cheers, Alastair. That could be very useful (at least for me

On 24 November 2010 13:27, Bill Wendling <wendling at apple.com> wrote: > There are two different bits of information in the proposal that address this: the "unwind edge" from the invoke and the region number. It's the "unwind edge" which carries the bit of information that you're asking about. My mental view of this is that the region number correlates to the

Hi, > Can anyone tell me if invoke/unwind is stable in 2.3? I'm seeing some > really weird stuff -- unwinds are ending up in seemingly arbitrary places... > definitely not inside the caller's unwind block My target is x86. codegen doesn't know how to handle "unwind" on any target. You need to call the libgcc unwinding routines directly (or indirectly by

Jon Harrop wrote: > > Is it? I was just reading the documentation about LLVM's exception > handling > and it sounded ideal for my needs. How much of it does not work as the > docs > imply? > Jon, I ran into this issue in September and re-ignited this discussion in another thread, here: http://www.nabble.com/Unwinds-Gone-Wild-td18747589.html

On Thu, Jul 31, 2008 at 2:19 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi, > > > Can anyone tell me if invoke/unwind is stable in 2.3? I'm seeing some > > really weird stuff -- unwinds are ending up in seemingly arbitrary > places... > > definitely not inside the caller's unwind block My target is x86. > > codegen doesn't know how to

---------- Forwarded message ---------- From: Ryan Taylor <ryta1203 at gmail.com> Date: Mon, Nov 21, 2011 at 10:30 AM Subject: Re: [LLVMdev] Order of Basic Blocks To: Benjamin Kramer <benny.kra at googlemail.com> This worked, though the RPO_iterator apparently wasn't what I was looking for anyways, it seems it doesn't rreally go top->down. I have a simple example code,