search for: frameallocate

On Wed, Mar 4, 2015 at 12:36 AM, John McCall <rjmccall at apple.com> wrote: > > On Mar 3, 2015, at 2:25 PM, Reid Kleckner <rnk at google.com> wrote: > > > > I realized that WinEH preparation can probably be a lot less invasive > than it is currently. > > > > Initially, when I was thinking about recovering the address of an object > in a parent stack

I realized that WinEH preparation can probably be a lot less invasive than it is currently. Initially, when I was thinking about recovering the address of an object in a parent stack frame, I thought about it in terms of "let's allocate something at a fixed offset from ebp to keep things simple". That line of thinking suggested that we needed this thing to be fundamentally different

...d, but I wondered if CodeExtractor might not be a better starting point. What do you think? Also, at the moment I’m more or less ignoring the frame variable issue. My ValueMaterializer is just creating new allocas with the name I want. I think that will be easy enough to patch up once your llvm.frameallocate stuff is in place. The implication of this is that right now I’m not looking for live variables before I start outlining, I’m just picking them up as I go. It seems like that may need to change. -Andy From: Reid Kleckner [mailto:rnk at google.com] Sent: Wednesday, December 03, 2014 1:32 PM To:...

...t;type> <pers_fn> cleanup [at handler] <clause>* <clause> := catch <type> <value> [at handler] <clause> := filter <array constant type> <array constant> Outlined handlers will reference frame variables from the parent function using the llvm.frameallocate and llvm.framerecover functions. Any frame variable which must be referenced from a catch or cleanup handler will be moved into a block allocated by llvm.frameallocate. When the handlers are called, the parent function's frame pointer is passed as the second argument to the call. The handler...

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

> We should also think about how to call std::terminate when cleanup dtors throw. The current representation for Itanium is inefficient. As a strawman, I propose making @__clang_call_terminate an intrinsic: … That sounds like a good starting point. > Chandler expressed strong concerns about this design, however, as @llvm.eh.get_capture_block adds an ordering constraint on CodeGen. Once

...t;type> <pers_fn> cleanup [at handler] <clause>* <clause> := catch <type> <value> [at handler] <clause> := filter <array constant type> <array constant> Outlined handlers will reference frame variables from the parent function using the llvm.frameallocate and llvm.framerecover functions. Any frame variable which must be referenced from a catch or cleanup handler will be moved into a block allocated by llvm.frameallocate. When the handlers are called, the parent function's frame pointer is passed as the second argument to the call. The handler...

...tions intrinsic will return an i8* that will feed into an indirectbr terminator. Similar to SjLj, SSA values live across the landing pad entrances and exits will be demoted to stack allocations. Unlike SjLj, to allow access from outlined landing pad code, the stack memory will be part of the @llvm.frameallocate block. Here's how _Z4testv would look after preparation: define void @_Z4testv() #0 { entry: %frame_alloc = call i8* @llvm.frameallocate(i32 2) %capture_block = bitcast i8* %frame_alloc to %captures._Z4testv* %outer = getelementptr %captures._Z4testv* %capture_block, i32 0, i32 0 %inn...

> We'd have to hoist a + b to somewhere that dominates L1 and L2. I think the only BB in your program that dominates is the entry block I don't follow. What path do you see from entry to either L1 or L2 that doesn't pass through the indirectbr? In order to reach either L1 or L2, the call to maybe_throw() must raise an exception (else we'd return 0 from foo), the exception must

Yes, it seems like WinEHPrepare should always be able to move landing pad code to somewhere appropriate. Even if there's some involved code to handle the cases that force #1, it's great that the complexity is contained in WinEHPrepare. I'm still confused about the apparent lack of constraints after WinEHPrepare. Can we simply require/assume that WinEHPrepare be run after any passes