search for: landingpads

...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 things via their landingpads would need to add similar intrinsics to extract them, like the @llvm.eh.exceptioncode intrinsic that SEH uses). But that would require updating all the front-ends generating landingpads, and be awkward for any target personality routines that literally do pass a struct to the landing pad (are ther...

...s to lump themselves into EHPersonality::Unknown. As for supporting selector and exception pointer extraction for landingpad of token type, I think you'll want to look at the handling of the @llvm.eh.exceptionpointer intrinsic that's used with catchpads and basically do the same thing with landingpads. Thanks -Joseph From: Chen Li [mailto:meloli87 at gmail.com] Sent: Saturday, December 5, 2015 12:34 AM To: Joseph Tremoulet <jotrem at microsoft.com> Cc: David Majnemer <david.majnemer at gmail.com>; Igor Laevsky <igor at azulsystems.com>; llvm-dev <llvm-dev at lists.llvm.or...

> On Dec 1, 2015, at 11:14 PM, David Majnemer <david.majnemer at gmail.com> wrote: > > While we support 'opaque' types nested within struct types, they are not exactly battle tested: > > $ cat t.ll > %opaque_ty = type opaque > > %struct_ty = type { i32, %opaque_ty } > > define %struct_ty @f(%struct_ty* %p) { > %load = load %struct_ty,

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

Hi David, Sorry to bother you, but I would like to get some suggestions on your recent work of token type. I’m currently working on changing gc.statepoint to return a token type instead of a i32 type. The reason is that with the current implementation, gc.statepoint could potentially be fed into PHI nodes, and break RewriteStatepointsForGC pass later. Using token type would help us to avoid

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 01/11/2012 02:37, Duncan Sands wrote: >> 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 undefined? > if it doesn't match a clause then the exception continues to be unwound. > Note that you can match a catch clause without being equal

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

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

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

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 undefined? 2. What is 'somety'? Shouldn't it maybe say

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 was listed? Or behavior is undefined? if it doesn't

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>

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

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

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

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

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 >