similar to: [LLVMdev] LLVMdev Digest, Vol 86, Issue 5

On Aug 2, 2011, at 10:28 AM, Duncan Sands wrote: >>>> Is it intended that "cleanup ty_1, ty_2" potentially be different to >>>> "cleanup ty_1 cleanup ty_2"? Perhaps this is useful for funky personality >>>> functions. >>>> >>> Yeah. One can basically interleave the catches and filters. But having two catch or two filter

Hi Chris, >>> Is it intended that "cleanup ty_1, ty_2" potentially be different to >>> "cleanup ty_1 cleanup ty_2"? Perhaps this is useful for funky personality >>> functions. >>> >> Yeah. One can basically interleave the catches and filters. But having two catch or two filter clauses in a row should be semantically the same as the

On Aug 1, 2011, at 11:13 PM, Bill Wendling wrote: >>> The 'landingpad' instruction replaces the current 'llvm.eh.exception' and >>> 'llvm.eh.selector' intrinsics. >>> >>> // Syntax: >>> >>> %res = landingpad<somety> personality<ty> <pers_fn> <clause>+ >>> >>> where

On Jul 31, 2011, at 11:06 AM, Duncan Sands wrote: >> //===-------------------------- >> // The 'landingpad' Instruction >> // >> >> The 'landingpad' instruction replaces the current 'llvm.eh.exception' and >> 'llvm.eh.selector' intrinsics. >> >> // Syntax: >> >> %res = landingpad<somety>

Hi Bill, > Please read this proposal and send me your comments, suggestions, and concerns. this proposal looks great to me. Thanks for working on it. I have a few minor comments, see below. > //===-------------------------- > // The 'landingpad' Instruction > // > > The 'landingpad' instruction replaces the current 'llvm.eh.exception' and >

On Fri, Jul 22, 2011 at 10:29 PM, Bill Wendling <wendling at apple.com> wrote: [...] > //===-------------------------- > // The 'landingpad' Instruction > // > > The 'landingpad' instruction replaces the current 'llvm.eh.exception' and > 'llvm.eh.selector' intrinsics. > > // Syntax: > >  %res = landingpad <somety>

What? Yet another EH proposal?! This one is different from the others in that I'm planning to start implementing this shortly. But I want your feedback! I've all ready gotten a lot of feedback from Chris, John, Jim, Eric, and many others. Now is your turn! Please read this proposal and send me your comments, suggestions, and concerns. -bw

Hi Bill, Thanks for working on this. Is there a reference for the function attribute uwtable, or is it to be defined as part of this effort? Thanks in advance Garrison On Jul 23, 2011, at 1:29, Bill Wendling wrote: > What? Yet another EH proposal?! This one is different from the others in that > I'm planning to start implementing this shortly. But I want your feedback! I've

On Aug 4, 2011, at 2:03 PM, Peter Lawrence wrote: > Bill et al, > I haven't really thought this through (I've never been a fan of exception specifications), > but it seems that inlining functions that do have exception specifications, and hence filter > operands in their landing-pads, isn't so obvious... > > if you want to inline > > void

Bill, I suspect we're talking about two different aspects, I think you are saying that there is an ability for the DWARF Actions Table to contain multiple lists, including multiple filter lists - no disagreement there, I am saying that for any one landing-pad it might not make sense for it to be able to have more than one filter list. -Peter Lawrence. On Aug 4, 2011, at 2:38

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

Hi everyone! I've been silently working on the previous exception handling proposal I published last year (http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-November/027311.html). However, there were some major deficiencies in it. After discussing this further with Jim Grosbach and John McCall, we've come up with another proposal. As you can see, it incorporates the idea of

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 Aug 4, 2011, at 2:58 PM, Peter Lawrence wrote: > Bill, > I suspect we're talking about two different aspects, > I think you are saying that there is an ability for the DWARF Actions Table > to contain multiple lists, including multiple filter lists - no disagreement > there, > I am saying that for any one landing-pad it might not make sense > for it to be able

On Jul 23, 2011, at 4:15 PM, Bill Wendling wrote: > On Jul 23, 2011, at 2:00 AM, Jakob Stoklund Olesen wrote: >> Yes. You scared me with 'requires considerable care'. Does that mean anything other than 'you have to duplicate the landing pad instead of splitting the unwind edge'. Is special magic required to duplicate a landingpad instruction? >> > There

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

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

Bill, ooops, yes, I described the meaning of "throw(A)" backwards, but I still think my example shows why you cannot merge LandingpadInst while inlining because multiple filter-lists on a LandingpadInst don't make sense. Perhaps I'm reading your original spec wrong, perhaps I'm mis-reading Duncan's emails, but I read them to mean that your syntax supports

On Jul 23, 2011, at 2:00 AM, Jakob Stoklund Olesen wrote: > On Jul 23, 2011, at 1:11 AM, Bill Wendling wrote: > >> On Jul 22, 2011, at 11:44 PM, Jakob Stoklund Olesen wrote: >>> Could we add: >>> >>> - A landing pad block is not the destination of any other kind of terminator. Only unwind edges are allowed. >>> >>> - The landingpad