similar to: [LLVMdev] RFC: Exception Handling Proposal II

Are you suggesting having different semantics for different chunks of the IR graph? -- Eric On Thu, Nov 25, 2010 at 2:33 AM, Renato Golin <rengolin at systemcall.org>wrote: > On 25 November 2010 07:51, Duncan Sands <baldrick at free.fr> wrote: > > If you got to XYZ because an instruction threw an exception before %x was > > defined, then in XYZ you are using %x which

On 25 November 2010 07:51, Duncan Sands <baldrick at free.fr> wrote: > If you got to XYZ because an instruction threw an exception before %x was > defined, then in XYZ you are using %x which was never defined.  In effect > the definition of %x in bb does not dominate the use in XYZ.  I think the > solution is to say that in XYZ you are not allowed to use any values defined >

Hi Renato, > On 25 November 2010 07:51, Duncan Sands<baldrick at free.fr> wrote: >> If you got to XYZ because an instruction threw an exception before %x was >> defined, then in XYZ you are using %x which was never defined. In effect >> the definition of %x in bb does not dominate the use in XYZ. I think the >> solution is to say that in XYZ you are not allowed

Hi Nick, > Just to throw out another perspective, I've wondered about optimizations we could do if we designed a new personality function. In particular, I'd like to eliminate the use of landing pads for destructing locals. Instead the LSDA would encode the pc liveness ranges of local objects, their location in the stack frame, and their destructor functions. Then the new

Just to throw out another perspective, I've wondered about optimizations we could do if we designed a new personality function. In particular, I'd like to eliminate the use of landing pads for destructing locals. Instead the LSDA would encode the pc liveness ranges of local objects, their location in the stack frame, and their destructor functions. Then the new personality function

On Nov 24, 2010, at 5:47 AM, Renato Golin wrote: >> So the above code would look something like this: >> >> entry: >> invoke @f.run() to %bb unwind to %FooCleanup region(1) >> bb: >> invoke @b.run() to %bb2 unwind to %BarCleanup region(1) >> bb2: >> invoke @z.run() to %bb3 unwind to %BazCleanup region(1) >> ... >> BazCleanup:

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 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 25 November 2010 11:03, Duncan Sands <baldrick at free.fr> wrote: > I don't understand what you are saying.  Cleanups (e.g. destructors) Hi Duncan, Cleanup landing pads normally call destructors, but they're not a destructor themselves. I'm simply saying that compiler generated blocks (such as cleanups) should never depend on user variables. But I get what you're

On Nov 24, 2010, at 9:01 PM, Bill Wendling wrote: > On Nov 24, 2010, at 6:41 PM, John McCall wrote: >> What you mean is that, given a resume or invoke edge, we need to be able to find the dispatch for the target region. There are ways to make that happen without tagged edges; for example, you could make the landing pad a special subclass of BasicBlock with a pointer to the dispatch,

Hi Bill, First, I like the idea of being more expressive in IR, since the old exception handling style didn't quite express exception handling, but alternate paths (resume/unwind). That made DwarfException.cpp a big hack. ;) It also makes the front-end engineer's life a lot easier, since there is less need to keep a long list of global state for all current landing pads, clean up areas,

On Nov 24, 2010, at 11:18 AM, John McCall wrote: > On Nov 24, 2010, at 5:36 AM, Bill Wendling wrote: >> Ah ha! I think I had a different mental model than you did. Or at least I remembered things differently from the discussion. :-) For me, there is one dispatch per region, which is why I had the region number associated with the invokes as well as the "unwind to" edge coming

On Nov 24, 2010, at 6:41 PM, John McCall wrote: > On Nov 24, 2010, at 5:07 PM, Bill Wendling wrote: > >> On Nov 24, 2010, at 11:18 AM, John McCall wrote: >> >>> I think my model has some nice conceptual advantages; for one, it gives you the constraint that only EH edges and dispatch instructions can lead to landing pads, which I think will simplify what EH

On Nov 24, 2010, at 5:36 AM, Bill Wendling wrote: > On Nov 24, 2010, at 4:58 AM, John McCall wrote: >> >>> The object 'f' is in a different cleanup area than 'b' which, in turn >>> is in a different area than 'z'. These three regions should point to >>> three different landing pads (or different offsets in the same landing >>>

Hi Renato, >> I don't understand what you are saying. Cleanups (e.g. destructors) > > Hi Duncan, > > Cleanup landing pads normally call destructors, but they're not a > destructor themselves. I'm simply saying that compiler generated > blocks (such as cleanups) should never depend on user variables. I see what you are saying now. Unfortunately optimizations

On Nov 24, 2010, at 5:07 PM, Bill Wendling wrote: > On Nov 24, 2010, at 11:18 AM, John McCall wrote: > >> On Nov 24, 2010, at 5:36 AM, Bill Wendling wrote: >>> Ah ha! I think I had a different mental model than you did. Or at least I remembered things differently from the discussion. :-) For me, there is one dispatch per region, which is why I had the region number

On Nov 24, 2010, at 11:49 PM, John McCall wrote: > On Nov 24, 2010, at 9:01 PM, Bill Wendling wrote: >> On Nov 24, 2010, at 6:41 PM, John McCall wrote: >>>> We know from experience that once this information is lost, it's *really* hard to get it back again. That's what DwarfEHPrepare.cpp is all about, and I want to get rid of that pass because it's a series of

On Nov 24, 2010, at 2:59 AM, Renato Golin wrote: > Hi Bill, > > First, I like the idea of being more expressive in IR, since the old > exception handling style didn't quite express exception handling, but > alternate paths (resume/unwind). That made DwarfException.cpp a big > hack. ;) > > It also makes the front-end engineer's life a lot easier, since there >

>> I hadn't quite got the role of the invoke in your intermediary model, >> now I get it. ;) >> >> I think we should ultimately treat calls like instructions and not >> mark them in any specific way regarding EH. >> > I totally agree. :-) I think everyone wants to get rid of invoke, but that is hard. One problem is that you want to keep the SSA property

Hi Bill, this proposal seems strangely complicated. I don't see the advantage of the dispatch instruction over just attaching the information to each invoke. Right now you have invoke void @_Z3foov() to label %invcont unwind label %catch.handlers catch.handlers: landingpad dispatch resume to label %... catches [ %struct.__fundamental_type_info_pseudo* @_ZTIi, label