similar to: [LLVMdev] Exception Handling Rewrite Branch

I have nothing to contribute other than to ask if this rewrite will bring clang's -fno-exceptions behavior inline with GCC's. According to this comment: http://llvm.org/bugs/show_bug.cgi?id=9171#c5 clang disables both C++ and Objective-C exceptions with that option whereas GCC only disables them for C++. Of course, this may have already been fixed in clang in the 5 months since I reported

<dropping cfe-dev> On Jul 26, 2011, at 4:16 AM, Bill Wendling wrote: > For those who are playing along, I've started on the exception handling rewrite following the document and comments from this thread: > > http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-July/041748.html > > The repositories are: > >

On Jul 26, 2011, at 11:00 PM, Chris Lattner wrote: > On Jul 26, 2011, at 4:16 AM, Bill Wendling wrote: > >> For those who are playing along, I've started on the exception handling rewrite following the document and comments from this thread: >> >> http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-July/041748.html >> >> The repositories are: >>

On Jul 27, 2011, at 1:08 AM, Bill Wendling wrote: >>> Progress Report: >>> >>> I created the two new instructions: landingpad and resume. Hand-modified code can run through the assembler and disassembler and emit the same code. The verifier can verify basic properties of the landingpad instruction. >> >> Hi Bill, >> >> Any reason to do this

On Jul 22, 2011, at 10:29 PM, Bill Wendling wrote: > // Restrictions: > > There are several new invariants which will be enforced by the verifier: > > 1. A landing pad block is a basic block which is the unwind destination of an > invoke instruction. > 2. A landing pad block must have a landingpad instruction as its first non-PHI > instruction. > 3. The landingpad

On Jul 22, 2011, at 11:44 PM, Jakob Stoklund Olesen wrote: > On Jul 22, 2011, at 10:29 PM, Bill Wendling wrote: > >> // Restrictions: >> >> There are several new invariants which will be enforced by the verifier: >> >> 1. A landing pad block is a basic block which is the unwind destination of an >> invoke instruction. >> 2. A landing pad block

Guys, on second thought... doesn't making the exception registers live from the InvokeInst to the LandingpadInst create problems for critical-edge-splitting ? if a landingpad-edge is critical and needs to be split, won't we be creating and inserting a new BB between the "invoke-block" and the "landingpad-block", and if we do then isn't there the

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>

On Jul 22, 2011, at 11:52 PM, Cameron Zwarich wrote: > On Jul 22, 2011, at 11:44 PM, Jakob Stoklund Olesen wrote: > >> On Jul 22, 2011, at 10:29 PM, Bill Wendling wrote: >> >>> // Restrictions: >>> >>> There are several new invariants which will be enforced by the verifier: >>> >>> 1. A landing pad block is a basic block which is

On Jul 27, 2011, at 8:02 AM, Chris Lattner wrote: > On Jul 27, 2011, at 1:08 AM, Bill Wendling wrote: > >>>> Progress Report: >>>> >>>> I created the two new instructions: landingpad and resume. Hand-modified code can run through the assembler and disassembler and emit the same code. The verifier can verify basic properties of the landingpad

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 instruction must only appear at the top of a landing pad. It cannot appear in any other block, or

On Jul 22, 2011, at 11:44 PM, Jakob Stoklund Olesen wrote: > On Jul 22, 2011, at 10:29 PM, Bill Wendling wrote: > >> // Restrictions: >> >> There are several new invariants which will be enforced by the verifier: >> >> 1. A landing pad block is a basic block which is the unwind destination of an >> invoke instruction. >> 2. A landing pad block

On Aug 5, 2011, at 10:57 AM, Peter Lawrence wrote: > However it seems that if a landingpad-block has multiple predecessors (often the case, > multiple InvokeInst in the main body of a try-statement all go to the same landingpad- > block), then you cannot move the LandingpadInst in order to break a critical edge unless > you do it for _all_ landingpad-block predecessor edges

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

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

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

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