search for: ehptr

...abel %cleanup.obj to label %nextaction unwind from label %cleanup.obj ; unwinds out of the function, hook it up to the unwind edge of an inlined call site For Itanium, tail merging is profitable and doable with phis, so we might want to do this instead: recover to label %endcatchbb unwind i8* %ehptr to label %nextaction unwind i8* %ehptr ; unwinds out of the function, hook it up to the unwind edge of an inlined call site Itanium requires threading the active exception pointer through to the next action or _Unwind_Resume, so it passes along an SSA value. MSVC needs this weird kind of contro...

...cleanup.obj ; unwinds out of the function, hook it > up to the unwind edge of an inlined call site > > > > For Itanium, tail merging is profitable and doable with phis, so we might > want to do this instead: > > > > recover to label %endcatchbb > > unwind i8* %ehptr to label %nextaction > > unwind i8* %ehptr ; unwinds out of the function, hook it up to the > unwind edge of an inlined call site > > > > Itanium requires threading the active exception pointer through to the > next action or _Unwind_Resume, so it passes along an SSA valu...

...cleanup.obj ; unwinds out of the function, hook it > up to the unwind edge of an inlined call site > > > > For Itanium, tail merging is profitable and doable with phis, so we might > want to do this instead: > > > > recover to label %endcatchbb > > unwind i8* %ehptr to label %nextaction > > unwind i8* %ehptr ; unwinds out of the function, hook it up to the > unwind edge of an inlined call site > > > > Itanium requires threading the active exception pointer through to the > next action or _Unwind_Resume, so it passes along an SSA valu...

> 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

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

...ret i32 %s3 } But even if we aren't smart enough to do #3, which could implement #1 by additional outlining. It's ugly though. =/ In practice, I don't think this situation will occur very often because the catch blocks look like this: catch_int: call void @llvm.eh.begincatch(i8* %ehptr) ... ; user code call void @llvm.eh.endcatch() ... ; rejoin normal control Anything we can hoist out of "user code" here can usually be sunk back in. If it's not trivial like a hoisted store to an unescaped internal global, then we'll have to emit something that looks like...