search for: resume_unwind

...tion). IE cosmetics >> do matter. > > I would be fine with still calling resume "unwind", but the new instruction > does need to carry extra information. It should not be called "unwind" since it is different than the old thing. I would be supportive of "resume_unwind" or something like that though. -Chris

...n 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 questio...

...>> do matter. >> >> I would be fine with still calling resume "unwind", but the new instruction >> does need to carry extra information. > > It should not be called "unwind" since it is different than the old thing. I would be supportive of "resume_unwind" or something like that though. For what it's worth, it serves exactly the same purpose as the old thing, except actually possible to reliably implement. John.

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

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

...ial 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 Jul 27, 2011, at 10:27 AM, Peter Lawrence wrote: > 3.b) I have been thinking about other possible control-flow-graph invariants of the > landingpad blocks and the catch blocks that they lead to, but so far have not come up > with very muchl, I wonder if anyone else is thinking about this...?... > > for example cleanups come before __cxa_begin_catch, but it isn't clear what

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