search for: framerecover

...32 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 ()* @parent to i8*), i8* %fp, i32 0) %b.i8 = call i8* @llvm.framerecover(i8* bitcast (i32 ()* @parent to i8*), i8* %fp, i32 1) %a = bitcast i8* %a.i8 to i32* %b = bitcast i8* %b.i8 to i32* store i32 1, i32* %a store i32 2, i32* %b ret void } declare i8* @llvm.frameaddr...

...ress(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 ()* @parent to > i8*), i8* %fp, i32 0) > > %b.i8 = call i8* @llvm.framerecover(i8* bitcast (i32 ()* @parent to > i8*), i8* %fp, i32 1) > > %a = bitcast i8* %a.i8 to i32* > > %b = bitcast i8* %b.i8 to i32* > > store i32 1, i32* %a > > st...

...ted to this approach, I just want to preserve functionality until we implement the de-commoning part of EH preparation, which I figured we could do later, since it's one of the more obscure corner cases. Also, __finally is pretty rare, so it's not too crazy to teach the inliner how to undo framerecover and let the optimization fall out that way. > > tail merging could kick in like you mention. Undoing this would be and > currently is the job of WinEHPrepare. I guess I felt like the extra > representational complexity wasn't worth the confidence that it would buy us > > For...

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(); }

...leanup 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:22 PM, Joseph Tremoulet <jotrem at microsoft.com> wrote: > > teach the inliner how to undo framerecover and let the optimization > fall out that way > > You'd still have the problem that the referenced variables were > frameescaped and appear to be read/written at unrelated calls. > > > > > __finally is pretty rare > > `__finally` may be rare in SEH code, but `fin...

...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:22 PM, Joseph Tremoulet <jotrem at microsoft.com> > wrote: > > > teach the inliner how to undo framerecover and let the optimization > fall out that way > > You'd still have the problem that the referenced variables were > frameescaped and appear to be read/written at unrelated calls. > > > > > __finally is pretty rare > > `__finally` may be rare in SEH code, but `fin...

...gt; 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 handlers will use this frame...

Just as an off-the-cuff idea that I haven’t thought through at all, what would you think of the possibility of replacing this: %12 = call i32 @llvm.eh.typeid.for(i8* bitcast (%eh.CatchHandlerType* @llvm.eh.handlertype.H.0 to i8*)) %matches7 = icmp eq i32 %sel6, %12 with this: %matches7 = call i32 @llvm.eh.cmp.selector(i32 %sel6, i8* bitcast (%eh.CatchHandlerType* @llvm.eh.handlertype.H.0

...gt; 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 handlers will use this frame...

...s MachineFunctions from IR Functions. This is the pass that will be responsible for the split. It will maintain information about the offsets of static allocas in FunctionLoweringInfo, and will throw it away when all funclets have been generated for this function. This means we don’t need to insert framerecover calls anymore. Generating EH state numbers for the TryBlockMap and StateUnwindTable is a matter of building a tree of EH blocks and invokes. Every unwind edge from an invoke or an EH block represents that the instruction is a child of the target block. If the unwind edge is empty, it is a child of...

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