search for: landingpad

> I dont have a concrete design right now and I am happy to take any other ideas Three ideas come to mind, none of which are perfect: 1) I'm tempted to say that now that we have token type, landingpad should generally produce a token, the pointer should be extracted with the @llvm.eh.exceptionpointer intrinsic instead of an extractvalue, and the selector should likewise be extracted with a new @llvm.eh.exceptionselector intrinsic instead of extractvalue (and personalities that communicate other...

It seems a little backwards to me to check the landingpad's type as the first check, since the personality dictates the landingpad's type. That said, yes I see how #4 is expedient in allowing personalities using the two main types to lump themselves into EHPersonality::Unknown. As for supporting selector and exception pointer extraction for land...

...t;isSized() && "Cannot getTypeInfo() on a type that is unsized!"' failed. Thanks David! I’ve actually hacked to add token type into struct type and ended up with the same failure as above. I will take a look at the catchpad and cleanuppad code, and create a patch to add token landingpad and have you review it. thanks, chen > > As a practical matter, I fear nesting 'token' types within struct types will have similar issues. Beyond that, the design philosophy behind 'token' is that it is incredibly opaque and permitting it to nest inside a struct creates sc...

...h is that it's easier for existing front-ends to adopt the new exception handling design. The heart of the proposal is to directly associate unwinding information for an invoke with the invoke, and to directly expose the values produced in the landing pad. We do this by introducing a new 'landingpad' instruction which is always required to the first non-phi instruction in the 'unwind' block of a landing pad block. Because of this direct association, it is always possible to find the invoke for a landing pad, and always possible to find the landing pad for an invoke. The 'land...

...te: > >> // 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 instruction must be the first non-PHI instruction in the >> landing pad block. >> 4. Like indirect branches, splitting the critical edge to a landing pad block >> requires considerable care, an...

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 possibility of the register...

...e_call, i32 1, i32 0, i64 addrspace(1)* %obj, i32 0, i32 5, i32 0, i32 -1, i32 0, i32 0, i32 0, i64 addrspace(1)* %obj, i64 addrspace(1)* %obj1) to label %invoke_safepoint_normal_dest unwind label %exceptional_return invoke_safepoint_normal_dest: … exceptional_return: %landing_pad = landingpad { i8*, i32 } cleanup %relocate_token = extractvalue { i8*, i32 } %landing_pad, 1 %obj.relocated1 = call coldcc i64 addrspace(1)* @llvm.experimental.gc.relocate.p1i64(i32 % relocate_token, i32 13, i32 13) %obj1.relocated1 = call coldcc i64 addrspace(1)* @llvm.experimental.gc.relocate...

...1, 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 instruction must be the first non-PHI instruction in the > landing pad block. > 4. Like indirect branches, splitting the critical edge to a landing pad block > requires considerable care, and SplitCriticalEdge...

...ote that you can match a catch clause without being equal to the type > in the catch clause (for example because the catch clause type represents > some class B, and thus will also match a class A if B derives from A). This also means, that in case of multiple exception types handled by one landingpad instruction, type checking is essentially done twice now, once in the landingpad (to match catch or filter), and once more in the code that branches to the handler of the particular type after the landingpad. Before checking was done only once. I think, because of this, new landingpad mechanism...

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 following non-phi instructions. >> > Most of this is covered by 2&3. But it would be good to explicitly state that a landingpad instruction can appear only in a landing pad block. Right....

...for > existing front-ends to adopt the new exception handling design. > > The heart of the proposal is to directly associate unwinding information for an > invoke with the invoke, and to directly expose the values produced in the > landing pad. We do this by introducing a new 'landingpad' instruction which is > always required to the first non-phi instruction in the 'unwind' block of a > landing pad block. Because of this direct association, it is always possible to > find the invoke for a landing pad, and always possible to find the landing pad > for an in...

...Linux, the dwarf/system V ABI exception spec. The mechanism allows for both cleanup routines and catch handlers, where by cleanup handlers don't stop the search for a normal handler. The personality function (I guess no longer part of the standard, but a C++ thing) can also compare types of the landingpads. I'm having trouble understanding a few points. I would like to understand since I have exceptions in my language as well and want to make effective use of the model. 1. The way basic blocks come together often means you can have embedded try/catch handlers without an intervening function ca...

I am new to the landingpad (which is relatively new too). Documentation http://llvm.org/docs/LangRef.html#i_landingpad leaves some questions open: 1. What happens when actual exception type isn't listed in catch or filter clauses? Does it still return the corresponding structure like if it was listed? Or behavior is...

Hi Yuri, > I am new to the landingpad (which is relatively new too). > Documentation http://llvm.org/docs/LangRef.html#i_landingpad leaves some > questions open: > > 1. What happens when actual exception type isn't listed in catch or > filter clauses? Does it still return the corresponding structure like if > it w...

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> personality<ty> <pe...

On 30/09/16 20:10, Reid Kleckner wrote: > On Mon, Sep 19, 2016 at 4:42 AM, Jonas Maebe <jonas-devlists at watlock.be > <mailto:jonas-devlists at watlock.be>> wrote: > > So, can I use invoke and landingpad without using any of the other > exception handling intrinsics? (in combination with a dummy personality > function) Or will LLVM in all cases insist on using ehframe information, > a (C++-)ABI-compliant personality function, and possibly linking in > parts of its own ru...

...te: > >> // 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 instruction must be the first non-PHI instruction in the >> landing pad block. >> 4. Like indirect branches, splitting the critical edge to a landing pad block >> requires considerable care, an...

...ficData >> returns)? The Dwarf encoded format is not well suited for the type of >> exception handling I wish to do in my language. > I didn't understand the question, can you please be more explicit about > what > you want to do exactly. I want to write custom data at the landingpads. That is, when I call _Unwind_GetLanguageSpecificData I would like that to point to a structure that I have created. Currently it points to a Dwarf encoded table, action records, etc. A lot of my exception handling code is thus just there to decode the Dwarf information -- which seems optimized f...

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

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 > 'llvm.eh.selector' intrinsics. > > // Syntax: > > %res = landingpad<somety> personality<ty> <pers_fn> <clause>+ > &g...