search for: frameescape

...witch to an intrinsic. So instead, let's go back to using normal allocas and "blessing" each of them as escaped allocations that can be referenced from EH helpers. Here's what it would look like: define i32 @parent() { %a = alloca i32 %b = alloca i32 call void (...)* @llvm.frameescape(i32* %a, i32* %b) %fp = call i8* @llvm.frameaddress(i32 0) call void @helper_func(i8* %fp) %a_val = load i32, i32* %a %b_val = load i32, i32* %b %r = add i32 %a_val, %b_val ret i32 %r } define void @helper_func(i8* %fp) { %a.i8 = call i8* @llvm.framerecover(i8* bitcast (i32 ()* @pare...

...ing normal allocas and "blessing" each of > them as escaped allocations that can be referenced from EH helpers. Here's > what it would look like: > > > > define i32 @parent() { > > %a = alloca i32 > > %b = alloca i32 > > call void (...)* @llvm.frameescape(i32* %a, i32* %b) > > %fp = call i8* @llvm.frameaddress(i32 0) > > call void @helper_func(i8* %fp) > > %a_val = load i32, i32* %a > > %b_val = load i32, i32* %b > > %r = add i32 %a_val, %b_val > > ret i32 %r > > } > > > > define void...

...t; } > > } finally { > > do_finally(2); > } > > > > We'll end up with four calls to do_finally in this example. Does that seem > OK? > > > > If that much duplication isn't OK, you can also have your frontend do > early outlining without using frameescape. Instead of passing the frame > pointer, it would pass the address of each escaped local variable. If the > cleanup is simple, it'll be inlined and some locals may be eliminated, and > if not, the outlined funclet will only contain a single call with lots of > lea+push pairs. > &...

...nested case like: try { try { f(); } finally { do_finally(1); } } finally { do_finally(2); } We'll end up with four calls to do_finally in this example. Does that seem OK? If that much duplication isn't OK, you can also have your frontend do early outlining without using frameescape. Instead of passing the frame pointer, it would pass the address of each escaped local variable. If the cleanup is simple, it'll be inlined and some locals may be eliminated, and if not, the outlined funclet will only contain a single call with lots of lea+push pairs. On Tue, May 19, 2015 at 2...

...ing blocks, but it should be *way* easier with real basic block terminator instructions to mark handler transitions. > For __finally, we outline the finally body early in clang and emit two > calls to it as before, but passing in the frameaddress as an argument > > But then you have to frameescape any __finally-referenced local before > optimization, and doesn't that defeat the purpose of delaying funclet > outlining to EH preparation? > True. I'm not committed to this approach, I just want to preserve functionality until we implement the de-commoning part of EH preparation...

Hi, I have a question about the IR model for SEH filters (as I want to use the same model for CLR filters). In particular, when an outer filter is invoked before entering an inner finally, which piece of IR reflects the filter's side-effects? To take a concrete example, consider this C code: void foo() { int x; __try { x = 0; __try { x = 2; may_throw(); }

On Mon, May 18, 2015 at 12:03 PM, Joseph Tremoulet <jotrem at microsoft.com> wrote: > Hi, > > > > Thanks for sending this out. We're looking forward to seeing this come > about, since we need funclet separation for LLILC as well (and I have > cycles to spend on it, if that would be helpful). > > > > Some questions about the new proposal: > > >