On Dec 1, 2010, at 1:12 AM, Renato Golin wrote:> On 1 December 2010 07:04, Bill Wendling <wendling at apple.com> wrote: >> The unwind edge from an invoke instruction jumps to a landing pad. That landing pad contains code which performs optional cleanups, and then determines which catch handler to call (if any). If no catch handlers are applicable, the exception resumes propagation either to the next enclosing region or out of the function. > > Hi Bill, > > Looking good already! ;) >Thanks!>> ch.int: > > shouldn't the catch handlers have "landingpad" attributes? >I don't think they need it.>> ;; C's d'tor >> c.dtor: > > and the cleanups? >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 mean inserting useless "cleanup dispatches" that only resume to the block (see onto.catch.handlers for an example).>> yikes: >> call void @_ZSt9terminatev() noreturn nounwind >> unreachable > > and yikes? > > Can we standardize "yikes" as the official terminate handler name? :D >I wish! :-D>> Well? What do you think? Pretty cool, eh? :-) > > Yup. I think it's much more clear than the current scheme, at least > for C++ Itanium ABI (AFAICS). > > Can anyone try an Ada (or any other language) example to see if it > makes sense for them, too? >*Looks at Duncan* -bw
>> Can anyone try an Ada (or any other language) example to see if it >> makes sense for them, too? >> > *Looks at Duncan*I plan to look at this tonight. Ciao, Duncan.
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 mean inserting useless "cleanup dispatches" that only resume to the block (see onto.catch.handlers for an example).Hi Bill, All cleanups come from invoke's unwinds (from foo's call) and all catch handlers come from the main catch dispatch, so for that rule, they all should have it. Or that's what I understood... ;) Also, now I noticed a few things in your IR, could be just typos... (ie. I'm not being an ass, just checking I got it right) ;) 1. Your BB flow seem odd in the try block. You call foo() four times and then call the Ctors, rather than interpolating them as in the source code (otherwise, all calls to foo should unwind to the catch area, not cleanups). 2. In catch.handlers, the resume label is to %onto.catch.handlers, right? 3. In onto.catch.handlers you resume to %lpad. Which basic-block is this? Shouldn't this be a "resume_unwinding" call of some sort (if Q2 is right)? 4. Your catch handlers return void, shouldn't then branch to %return instead? In this case, a front-end would probably call that label a "%finally" and that would branch to %return, or return directly. Which brings me to my final question: In languages where the finally HAS to run, like Java, would that be a simple cleanup regions or do we need something special from catch's dispatch's resume AND %finally block? cheers, --renato
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 mean inserting useless "cleanup dispatches" that only resume to the block (see onto.catch.handlers for an example). > > Hi Bill, > > All cleanups come from invoke's unwinds (from foo's call) and all > catch handlers come from the main catch dispatch, so for that rule, > they all should have it. Or that's what I understood... ;) > > Also, now I noticed a few things in your IR, could be just typos... > (ie. I'm not being an ass, just checking I got it right) ;)I think I can answer a couple of those...> 1. Your BB flow seem odd in the try block. You call foo() four times > and then call the Ctors, rather than interpolating them as in the > source code (otherwise, all calls to foo should unwind to the catch > area, not cleanups).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.> 4. Your catch handlers return void, shouldn't then branch to %return > instead? In this case, a front-end would probably call that label a > "%finally" and that would branch to %return, or return directly.He did say it was simplified IR. Just imagine -simplify-cfg already did some tail duplication here.> Which brings me to my final question: In languages where the finally > HAS to run, like Java, would that be a simple cleanup regions or do we > need something special from catch's dispatch's resume AND %finally > block?Presumably that would just be encoded as a catch-all to the finally code followed by some encoding of a rethrow (e.g. an "unwind resume" to the next enclosing region, an 'unwind' instruction or some form of "resume_unwind()" call). If there were also catches, they'd probably need to explicitly execute the finally code (or if they again throw, have their unwind edges point to a dispatch with a catch-all to the finally code).
On Dec 1, 2010, at 2:37 AM, Renato Golin 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 mean inserting useless "cleanup dispatches" that only resume to the block (see onto.catch.handlers for an example). > > Hi Bill, > > All cleanups come from invoke's unwinds (from foo's call) and all > catch handlers come from the main catch dispatch, so for that rule, > they all should have it. Or that's what I understood... ;) > > Also, now I noticed a few things in your IR, could be just typos... > (ie. I'm not being an ass, just checking I got it right) ;) > > 1. Your BB flow seem odd in the try block. You call foo() four times > and then call the Ctors, rather than interpolating them as in the > source code (otherwise, all calls to foo should unwind to the catch > area, not cleanups). >I think you mean that it calls the Dtors on %c, %b, and %a. :-) It optimized the creation of the objects by not calling the empty constructors. bb1, bb2, and bb3 are the normal calls to the d'tors that we expect.> 2. In catch.handlers, the resume label is to %onto.catch.handlers, right? >Oh…I forgot to fill that in. It should to go %yikes.> 3. In onto.catch.handlers you resume to %lpad. Which basic-block is > this? Shouldn't this be a "resume_unwinding" call of some sort (if Q2 > is right)? >This was necessary to keep the invariant that only resume or unwind edges may jump to a landing pad (%lpad in this instance). Otherwise, I would have the invoke in a.dtor to directly to %lpad on the "normal" edge.> 4. Your catch handlers return void, shouldn't then branch to %return > instead? In this case, a front-end would probably call that label a > "%finally" and that would branch to %return, or return directly. >They could. It's an optimization that the back-end normally does. :-)> Which brings me to my final question: In languages where the finally > HAS to run, like Java, would that be a simple cleanup regions or do we > need something special from catch's dispatch's resume AND %finally > block? >I need to see how we do things today (Objective-C also has finally blocks). But I suspect that it will be a matter of having the catch handlers jumping to the finally block. In other words, I don't suspect that we need a different mechanism to handle this. -bw -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101201/ecd3bfb9/attachment.html>