similar to: [LLVMdev] unwinds to in the CFG

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

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

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 >>

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) {

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

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

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'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 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)

> 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

Hi all, Is there a way to walk through ALL the predecessors of a basic block in a CFG. I tried to iterate over the preds using this method for (pred_iterator PI = pred_begin(BB), E = pred_end(BB); PI != E; ++I) { BasicBlock *PredBB = *PI; } but this only gives the immediate predecessors for a basic block. For example, in this sample control flow graph. entry -> bb1 -> bb2 -> bb4

> 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 > >

Hi Pabhat, Have you checked out DepthFirstIterator? (include/llvm/ADT/ DepthFirstIterator.h). It provides an iterator abstraction to perform a forward/reverse DFS traversal of a graph. Many of the LLVM datatypes that represent graphs have a template specialization of the GraphTraits<> class which allows separate algorithms to treat them as graphs, walk them, etc. (Both BasicBlock

Hi, Well, yes i did try your suggestion but i keep on running into a compilation problem. The error is: llvm[0]: Compiling Hello.cpp for Release build (PIC) /home/saraswat/llvm/llvm-2.1/include/llvm/ADT/GraphTraits.h: In instantiation of `llvm::GraphTraits<llvm::ilist_iterator<llvm::BasicBlock> >': Hello.cpp:59: instantiated from here

Talin wrote: > Currently it states in the language manual that the results of division > by zero are undefined. However, I'm curious as to how you would normally > handle either divide by zero or other "hardware" exceptions (null > pointer dereference and so on) and turn them into LLVM exceptions. Ultimately, what we'd like to do is attach a bit to each

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

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

Hi, I want to instrument every control-flow edge in a CFG. What is the best way to do this ? I was thinking of getting a reference to the CFG using GraphTraits<Function *>. Is there a simple way to get the CFG handle? Thanks.

On May 8, 2008, at 9:35 PM, Nick Lewycky wrote: > Talin wrote: >> Currently it states in the language manual that the results of >> division >> by zero are undefined. However, I'm curious as to how you would >> normally >> handle either divide by zero or other "hardware" exceptions (null >> pointer dereference and so on) and turn them into

Dan Gohman wrote: > On May 8, 2008, at 9:35 PM, Nick Lewycky wrote: > >> Talin wrote: >>> Currently it states in the language manual that the results of >>> division >>> by zero are undefined. However, I'm curious as to how you would >>> normally >>> handle either divide by zero or other "hardware" exceptions (null