similar to: [LLVMdev] RFC: Native Windows C++ exception handling

Hi Reid, Thanks for the input. You wrote: > The @_Z4testv.unwind.1 helper just calls ~Inner(), but not ~Outer. That’s actually intentional. The thing to keep in mind is that all of the landing pads are going to be effectively removed by the time the final object image is generated. They are just there to facilitate the table generation, and in the __CxxFrameHandler3 case they don’t mean

I was thinking about this last night, and I came up with a third alternative which I think looks very promising. It’s basically a re-working of the previous alternative to use the landingpad concept rather than arbitrary fake logic, but it uses a single landing pad for the entire function that mimics the logic of the personality function to dispatch unwinding calls and catch handlers. I believe

Thanks, Reid. These are good points. So I guess that does take us back to something more like my original proposal. I like your suggestion of having some kind of “eh.actions” intrinsic to represent the outlining rather than the extension to landingpad that I had proposed. I was just working on something like that in conjunction with my second alternative idea. What I’d really like is to have

These are exactly the sorts of code transformations we want to allow by delaying the outlining until later. By keeping such code inlined in the parent function until after optimization, we enable a lot of core optimizations like SROA. For example, we should be able to completely eliminate wrappers like unique_ptr that would otherwise stay around due to the pointer escaped to the destructor call

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 Reid, I’ve worked through a few scenarios, and I think this is converging. I’m attaching a new example, which extends the one we’ve been working through to handle a few more cases. I wasn’t sure what you intended the first i32 argument in an llvm.eh.actions entry to be. I’ve been using it as a place to store the eh state that I’m associating with the action, but that’s kind of circular

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

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

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

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

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

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 >

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

Nice. This seems like a good starting design for some patches. I'm not sure exactly how step 3.a works. Does it stem from step 4.b which assigns the same eh_state to two catch handlers? It seems like these rules would come into play in these examples: // 'catch int' and 'catch float' have the same incoming eh_state range try { f(); } catch (int) { g(); } catch (float) { h();

Ah, ok. So if the outliner sees non-dispatch code in the landing pad area, it can find/create somewhere to put it and an appropriate eh.actions annotation to get an EH table generated that will ensure it gets executed appropriately at run-time (in this example, perform the add before invoking either handler); is that more or less the idea? That makes sense, thanks. I have the same question

On Sat, May 16, 2015 at 7:29 AM, Steve Cheng <steve.ckp at gmail.com> wrote: > On 2015-05-15 18:37:58 -0400, Reid Kleckner said: > > After a long tale of sorrow and woe, my colleagues and I stand here >> before you defeated. The Itanium EH representation is not amenable to >> implementing MSVC-compatible exceptions. We need a new representation that >> preserves

After a long tale of sorrow and woe, my colleagues and I stand here before you defeated. The Itanium EH representation is not amenable to implementing MSVC-compatible exceptions. We need a new representation that preserves information about how try-catch blocks are nested. WinEH background ------------------------------- Skip this if you already know a lot about Windows exceptions. On Windows,

On Mon, May 18, 2015 at 11:48 AM, Steve Cheng <steve.ckp at gmail.com> wrote: > On 2015-05-18 13:32:54 -0400, Reid Kleckner said: > >> >> Right, doing our own personality function is possible, but still has half >> the challenge of using __CxxFrameHandler3, and introduces a new runtime >> dependency that isn't there currently. Given that it won't save

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