similar to: [LLVMdev] LLVM Exception Handling

On 25 September 2010 23:46, Nathan Jeffords <blunted2night at gmail.com> wrote: > catch: >   %v = ptrtoint i8 * %x to i32 >   %r = icmp eq i32 %v, 255 >   br i1 %r, label %bad, label %worse > bad: >   ret i32 -1 > worse: >   ret i32 -2 > } If I understood correctly, you're trying to pass the clean-up flag through %x directly on the invoke call. But later avoid

I may me wrong, but I think Nathan used ints for demonstration purposes only. unwind always takes i8* argument that ideally should be a pointer to exception structure, variable %x in invoke is also typed i8*, it's not "untyped". Probably more llvm-ish syntax would be unwind i8* %x to label %catch to show the type explicitly. However throwing a pointer to a structure raises

On Sun, Sep 26, 2010 at 4:19 AM, Renato Golin <rengolin at systemcall.org>wrote: > On 25 September 2010 23:46, Nathan Jeffords <blunted2night at gmail.com> > wrote: > > catch: > > %v = ptrtoint i8 * %x to i32 > > %r = icmp eq i32 %v, 255 > > br i1 %r, label %bad, label %worse > > bad: > > ret i32 -1 > > worse: > > ret i32

On 27 September 2010 01:12, Nathan Jeffords <blunted2night at gmail.com> wrote: > How about this syntax: > invoke @method(i32 %arg) >   ret i32 %return_value to label %success_branch > unwind i8* %exception_pointer to label %error_branch > this makes the instruction self consistent, and self documenting I like it. What if the function returns void? Would you omit the whole

On Sun, Sep 26, 2010 at 5:08 AM, Eugene Toder <eltoder at gmail.com> wrote: > I may me wrong, but I think Nathan used ints for demonstration > purposes only. unwind always takes i8* argument that ideally should be > a pointer to exception structure, variable %x in invoke is also typed > i8*, it's not "untyped". Probably more llvm-ish syntax would be > >

On Sun, Sep 26, 2010 at 11:27 AM, Renato Golin <rengolin at systemcall.org>wrote: > On 26 September 2010 18:56, Nathan Jeffords <blunted2night at gmail.com> > wrote: > > The syntax for the invoke instruction is a little misleading. %x is a > value > > that is being generated by the instruction, not passed to is. It is no > > different in that regard as to

On 26 September 2010 13:08, Eugene Toder <eltoder at gmail.com> wrote: >  %s = invoke i32 @v(i32 %o) to label %ok >                   unwind %x to label %catch > ok: >  ret i32 %s > > catch: >  %type = call i32 @exception_type(i8* %x) >  %r = icmp eq i32 %type, 255 ; 255 is DivisionByZeroException type >  br i1 %r, label %bad, label %worse > > bad: >  ret

How about this syntax: invoke @method(i32 %arg) ret i32 %return_value to label %success_branch unwind i8* %exception_pointer to label %error_branch this makes the instruction self consistent, and self documenting -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100926/5de04087/attachment.html>

Ok, I see it. Works for me. On Sun, Sep 26, 2010 at 3:01 PM, Renato Golin <rengolin at systemcall.org>wrote: > On 26 September 2010 22:11, Nathan Jeffords <blunted2night at gmail.com> > wrote: > > The "exception" value will *always* be i8*, it is not possible for it to > be > > anything different. > > In the end, this a minor parser detail and it

On Sun, Sep 26, 2010 at 1:44 PM, Renato Golin <rengolin at systemcall.org>wrote: > On 26 September 2010 20:13, Nathan Jeffords <blunted2night at gmail.com> > wrote: > > I believe the perceived problem with using eh.exception is that > > is disassociates the source of the value with the invoke instruction that > > generated it. As far as reusing the landing pad,

This is a revision of the second exception handling proposal I sent out. You can see it here: http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-November/036484.html After much discussion, there are some changes to the proposal – some significant and some minor. One major point, this proposal does not address the issue of catching an exception thrown from a non-invoke instruction. However if done

(Mail system seems to have eaten this, sorry if it's a repeat) On Dec 8, 2007, at 12:48 AM, Duncan Sands wrote: > Hi Dale, > >> - Why was C++ claiming that every selector has a catch-all handler? > > this is easy: because the semantics of invoke require it. Yes, > really. > If unwinding reaches an invoke then control is required to jump to the > unwind basic

On Dec 9, 2007, at 1:01 PM, Duncan Sands wrote: > Hi Dale, > >> #include <cstdio> >> class A { >> public: >> A() {} >> ~A() {} >> }; >> void f() { >> A a; >> throw 5.0; >> } >> main() { >> try { >> f(); >> } catch(...) { printf("caught\n"); } >> } > > this example

Hi Dale, > #include <cstdio> > class A { > public: > A() {} > ~A() {} > }; > void f() { > A a; > throw 5.0; > } > main() { > try { > f(); > } catch(...) { printf("caught\n"); } > } this example indeed shows the problem. Let me explain to see if we agree on what the problem is. Suppose we don't artificially

Here is an alternative proposal to Bill's. It is closer to what we already have (which can be seen as a good or a bad thing!), and is also closer to what gcc does. It is more incremental than Bill's and introduces fewer new concepts. Executive summary ----------------- Remove the personality and list of catches out of eh.selector and stick them directly on invoke instructions. The

On 26 September 2010 20:13, Nathan Jeffords <blunted2night at gmail.com> wrote: > I believe the perceived problem with using eh.exception is that > is disassociates the source of the value with the invoke instruction that > generated it. As far as reusing the landing pad, that is still possible, it > would just require a phi node in the landing pad to bring all the different >

Hi Dale, > > ... Suppose we don't artificially add catch-alls to > > selectors. Then > > the above example compiles to: > > ... > I wasn't advocating this; agree it is wrong. it's maybe not as wrong as it seems since having an empty selector is equivalent to having a cleanup (IIRC) :) > > ... If you force a "cleanup" by changing the

On Dec 1, 2010, at 1:37 PM, Duncan Sands wrote: > Inlining > -------- > > Many a plausible seeming exception handling scheme 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

On Dec 10, 2007, at 11:38 AM, Duncan Sands wrote: >>> ... If you force a "cleanup" by changing the selector call to: >>> %eh_select8.i = tail call i32 (i8*, i8*, ...)* >>> @llvm.eh.selector.i32( i8* %eh_ptr.i, i8* bitcast (i32 (...)* >>> @__gxx_personality_v0 to i8*), i32 0) >>> then it doesn't work either: the unwinder observes that

I was thinking about this last night, and I came up with a third alternative which I think looks very promising. It’s basically a re-working of the previous alternative to use the landingpad concept rather than arbitrary fake logic, but it uses a single landing pad for the entire function that mimics the logic of the personality function to dispatch unwinding calls and catch handlers. I believe