search for: resumedest

...n branch to landing pads, that these cannot be split etc. Your rules mean that you can uniquely associate a dispatch instruction with each invoke unwind edge, so why not directly attach the dispatch information to the edge, i.e. to the invoke? > Syntax: > > dispatch resume to label<resumedest> How do you say: if nothing is matched, keep unwinding out of the function? Actually I don't see why <resumedest> is useful at all, since you can always place a complete set of all handlers into one dispatch, so redispatching is not needed. That said, it might be handy for reducing c...

...ritical edges may not be split. • The attribute may not be removed. Dispatch Instruction ==================== The dispatch instruction is the work horse of the exception handling design. It replaces the llvm.eh.selector and llvm.eh.typeid.for intrinsics. Syntax: dispatch resume to label <resumedest> catches [ <type> <val>, label <dest1> ... ] catchall [ <type> <val>, label <dest> ] personality [<type> <value>] filters [ <type> <val>, <type> <val>, ... ] The `catches', `cat...

...instruction at the end of the cleanup region so that you can associated the invoke to the decision point – the point where we determine which handler we need to execute. After we realized this, this proposal became the natural way. >> Syntax: >> >> dispatch resume to label<resumedest> > > How do you say: if nothing is matched, keep unwinding out of the function? > Actually I don't see why <resumedest> is useful at all, since you can always > place a complete set of all handlers into one dispatch, so redispatching is > not needed. That said, it migh...

...region and make it explicit in the IR. Dispatch Instruction -------------------- We intruduce a new instruction called "dispatch." This instruction holds most of the information necessary for the exception handler to work. Syntax: dispatch region(<value>) resume to label <resumedest> catches [ <type> <val>, label <dest> ... ] catchall [ <type> <val>, label <dest> ] filters [ <type> <val>, ... ] Description: * The "catchall", "catches", and "filters&quo...

Hi Bill, there are a couple of things I didn't understand about your proposal, for example how it interacts with inlining, whether it is feasible to do the "turn invoke-of-Unwind_Resume into a branch" optimization and also whether in "resumedest" you still plan to use _Unwind_Resume to continue unwinding up the stack. Could you please show what the LLVM IR would look like for the following example both before and after inlining, and if the optimization I mentioned is compatible with the dispatch instruction can you please show how th...

...k-ends won't understand old IRs at all), there is no point of keeping compatibility... > * The "catchall", "catches", and "filters" clauses are optional. If none are >  specified, then the landing pad is implicitly a "cleanup." > > * The <resumedest> basic block is the destination to unwind to if the type >  thrown isn't matched to any of the choices. > > * The "catches" clause is a list of types which the region can catch and the >  destinations to jump to for each type. > > * The "catchall" clause...

...etely removing the invoke. But I'm not opposed to removing the invoke. >> * The "catchall", "catches", and "filters" clauses are optional. If none are >> specified, then the landing pad is implicitly a "cleanup." >> >> * The <resumedest> basic block is the destination to unwind to if the type >> thrown isn't matched to any of the choices. >> >> * The "catches" clause is a list of types which the region can catch and the >> destinations to jump to for each type. >> >> * The &...