search for: catchret

...gt; could be helpful; we're eager to build our EH support in LLILC on top of > this. > A preliminary step was to push personality routines off of LandingPadInst and onto functions, this is already in trunk. On the IR front, we ended up with the following set of instructions: catcblock, catchret, cleanupblock, cleanupret, terminateblock Of these, I've locally added basic support for catchblock, catchret and cleanupret. I'm working on cleanupblock and terminateblock as we speak. We'll still need to hook up CodeGenPrep and SDAG up to the new representation. Extra hands will b...

...y, and landing in $t10 cannot be represented by LLVM IR today. Similarly in #4, the control starting from RtlRaiseException() passing through both _finally funclets then landing in $t10 was not seen. To precisely represent _local_unwind flow, our proposed solution is: * Add one more catchpad/catchret pair that forwards control to local_unwind target. I.e., this extra Catchpad is the reentrance point for the _local_unwind() runtime. * This catchpad address is used to pass to _local_unwind() runtime, instead of the original goto target address. * The local_unwind catchpad will be ha...

...gure out is how to call these funclets, they look like: Catch: "?catch$3@?0?m3 at 4HA": LBB4_3: # %BasicBlock26 pushl %ebp pushl %eax addl $12, %ebp movl %esp, -28(%ebp) movl $LBB4_5, %eax addl $4, %esp popl %ebp retl # CATCHRET cleanup: "?dtor$2@?0?m2 at 4HA": LBB3_2: pushl %ebp subl $8, %esp addl $12, %ebp movl %ebp, %eax movl %esp, %ecx movl %eax, 4(%ecx) movl $1, (%ecx) calll m2$Fin addl $8, %esp popl %ebp retl # CLEANUPRET What do I pass to these to get a valid frame...

..., !dbg !93 BasicBlock3: ; preds = %BasicBlock5, %BasicBlock2 %4 = load i32, i32* %csLoc0, !dbg !94 ret i32 %4, !dbg !94 BasicBlock4: ; preds = %2 %5 = catchpad within %3 [{ i8*, i8* }* @0, i32 0, i8* null], !dbg !93 catchret from %5 to label %BasicBlock5, !dbg !95 BasicBlock5: ; preds = %BasicBlock4 br label %BasicBlock3, !dbg !95 BasicBlock6: ; No predecessors! unreachable, !dbg !94 } (_elements_exception_handler is my exception handler...

On Wed, Jun 17, 2015 at 6:18 PM, Philip Reames <listmail at philipreames.com> wrote: > Since I haven't been following the thread closely, is there an updated > summary of the original proposal available? I know that various parts I > had concerns with (the unsplitable blocks for instance) got addressed, but > I'm having trouble tracking all the changes in discussion.

...documentation. The document is intended to aid LLVM developers who don't particularly care about WinEH but want to understand it enough to avoid breaking it. If we wanted to exploit this optimization opportunity, we would clip funclets out of the CFG and add edges from invokes to all possible catchret destinations. Then the CSR mask of the call would naturally provide the right register allocation barrier. On Thu, May 24, 2018 at 8:13 AM Jay K via llvm-dev <llvm-dev at lists.llvm.org> wrote: > https://llvm.org/docs/ExceptionHandling.html#wineh > > > No variables live in to or...

https://llvm.org/docs/ExceptionHandling.html#wineh > No variables live in to or out of the funclet can be allocated in registers. I don't think this is quite true. though it might be a useful simplification. Obviously it is true for volatile registers, but I believe the funclet receives a CONTEXT with the nonvolatiles restored. Obviously cumbersome to access, but it lets you enregister

...%BasicBlock5, %BasicBlock2>> %4 = load i32, i32* %csLoc0, !dbg !94 >> ret i32 %4, !dbg !94 >> >> BasicBlock4: ; preds = %2 >> %5 = catchpad within %3 [{ i8*, i8* }* @0, i32 0, i8* null], !dbg >> %!93>> catchret from %5 to label %BasicBlock5, !dbg !95 >> >> BasicBlock5: ; preds = >> %BasicBlock4>> br label %BasicBlock3, !dbg !95 >> >> BasicBlock6: ; No predecessors!>> unreachable,...

...finally occurs, we must "unwind" to the target code, not just "jump" to target label I'm not sure what you're trying to say here. In the Microsoft ABI, goto out of a catch block also calls into the unwinder. We have to run any destructors, and return from the funclet (catchret/cleanupret). * The call inside a _try is an invoke with EH edge. So it's perfectly modeled. If you call a nounwind function, the invoke will be transformed to a plain call. And we're likely to infer nounwind in many cases (for example, functions that don't call any other functi...

On 01/05/2017 12:17 PM, Reid Kleckner wrote: > On Thu, Jan 5, 2017 at 9:19 AM, Hal Finkel via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > On 01/05/2017 10:55 AM, Sanjoy Das wrote: > > Hi Hal, > > On Thu, Jan 5, 2017 at 6:12 AM, Hal Finkel <hfinkel at anl.gov > <mailto:hfinkel

Reply inline From: Ten Tzen <tentzen at microsoft.com> Sent: Wednesday, April 1, 2020 3:54 PM To: Eli Friedman <efriedma at quicinc.com>; llvm-dev <llvm-dev at lists.llvm.org> Cc: aaron.smith at microsoft.com Subject: [EXT] RE: [llvm-dev] [RFC] [Windows SEH] Local_Unwind (Jumping out of a _finally) and -EHa (Hardware Exception Handling) ? For goto in finally, why are you