similar to: [LLVMdev] How to handle divide-by-zero exception?

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

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

On May 9, 2008, at 10:04 PM, Nick Lewycky wrote: > Dan Gohman wrote: >> >> Having a dom tree with multiple roots, where blocks may >> not be dominated by the entry block is pretty scary. > > The dom tree code already supports it, because it already happens to > postdominator trees. There are some clients that will need to be > changed, but I think it's pretty

Is LLVM expressive enough to represent asynchronous exceptions? --------------------------------------------------------------- Summary: Need new LLVM instructions or extending of all instructions. C++ exceptions are synchronous: the compiler knows when/where they are being raised. Asynchronous exceptions can be raised at any time. For example, an integer divide-by-zero may raise an

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

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:

On Nov 28, 2010, at 1:57 PM, Bill Wendling wrote: > On Nov 28, 2010, at 2:59 AM, John McCall wrote: > >> On Nov 28, 2010, at 2:20 AM, Bill Wendling wrote: >> >>> On Nov 27, 2010, at 4:57 PM, John McCall wrote: >>> >>>> On Nov 25, 2010, at 3:03 AM, Duncan Sands wrote: >>>>> I'm pointing out that if the invoke instruction

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

On Jun 12, 2011, at 1:25 AM, Duncan Sands wrote: > Hi Sohail, > >> Is LLVM expressive enough to represent asynchronous exceptions? > > not currently. The first step in this direction is to get rid of the invoke > instruction and attach exception handling information to basic blocks. See > http://nondot.org/sabre/LLVMNotes/ExceptionHandlingChanges.txt > for a

On Wed, Dec 1, 2010 at 11:37 AM, Renato Golin <rengolin at systemcall.org> wrote: > On 1 December 2010 09:46, Bill Wendling <wendling at apple.com> wrote: >> Nor these. Basically, I want the basic block that's labeled a "landing pad" to be jumped to by only a dispatch resume or unwind edge of invoke. We could do this with the c.dtor and ch.int here, but it would

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

DISCLAIMER: I am SSA, LLVM and compiler ignorant, so take the following for what it is worth. What about logically breaking a (complex) SEH method into two logical methods, as per this pseudo-code as an example: ----------------------- foo(parameter-list) { leading-statements; try { try-statements; } catch(Execption0 ex0) { catch-0-statements; } . catch(ExceptionN exN) {

On Nov 28, 2010, at 3:47 PM, John McCall wrote: > This is well-formed SSA; the alloca instruction %x is in the entry block and thus dominates both the store in %try and the load in %catch. mem2reg wants to eliminate %x and replace the load in %catch with a fixed value. This involves looking at the value stored in %x at all predecessor points, which is a challenge because one of those

On 11-06-12 12:01 AM, Sohail Somani wrote: > Is LLVM expressive enough to represent asynchronous exceptions? > --------------------------------------------------------------- > > Summary: Need new LLVM instructions or extending of all instructions. > > C++ exceptions are synchronous: the compiler knows when/where they are > being raised. > > Asynchronous exceptions can

On Dec 2, 2010, at 1:40 AM, Duncan Sands wrote: > Two amendments: > >> The semantics of the invoke instruction are slightly modified: if an exception >> unwinds and it doesn't match anything in the list of catches and filters, >> and there is no cleanup, then control doesn't branch to the unwind label, >> unwinding simply continues out of the function. >

On Nov 28, 2010, at 2:59 AM, John McCall wrote: > On Nov 28, 2010, at 2:20 AM, Bill Wendling wrote: > >> On Nov 27, 2010, at 4:57 PM, John McCall wrote: >> >>> On Nov 25, 2010, at 3:03 AM, Duncan Sands wrote: >>>> I'm pointing out that if the invoke instruction >>>> is removed and catch information is attached to entire basic blocks, then

On Nov 28, 2010, at 2:20 AM, Bill Wendling wrote: > On Nov 27, 2010, at 4:57 PM, John McCall wrote: > >> On Nov 25, 2010, at 3:03 AM, Duncan Sands wrote: >>> I'm pointing out that if the invoke instruction >>> is removed and catch information is attached to entire basic blocks, then if no >>> care is taken then it is perfectly possible to use %x before

On 1 December 2010 11:11, Frits van Bommel <fvbommel at gmail.com> wrote: > Those are destructor calls for the case where none of the foo()s > throw. There are no ctor calls because the classes have trivial > constructors, which are no-ops. Indeed! Thanks! ;) > If there were also catches, they'd probably need to explicitly execute > the finally code (or if they again