[LLVMdev] Alternative exception handling proposal

Duncan Sands baldrick at free.fr
Thu Dec 2 01:40:58 PST 2010


Two amendments:

> The semantics of the invoke instruction are slightly modified: if an exception
> unwinds and it doesn't match anything in the list of catches and filters,
> and there is no cleanup, then control doesn't branch to the unwind label,
> unwinding simply continues out of the function.

in fact the new semantics would be that if an exception doesn't match then
it is unspecified whether it just unwinds straight through the invoke or
branches to the landing pad.  This forces front-ends to output code to
continue unwinding ("rewind" instruction, see below) if the selector does
not match any of the catches on the invoke.  This in turn ensures that inlining
works correctly.

> The rewind instruction
> ----------------------
>
> For extra goodness, I propose introducing a new instruction "rewind" that takes
> an exception pointer and selector value as arguments:
>     rewind<ptr>,<i32>

Actually the existing "unwind" instruction can be repurposed for this, as there
was no real need for rewind to take any arguments.  All that is needed is that
unwind be lowered to a call of eh.exception, which is then passed as the
argument to _Unwind_Resume,  In fact codegen already does this!

> Then after inlining this becomes:
>
>     eh.set.exception(%exception)
>     eh.set.selector(%selector)
>     br label %lpad

Using unwind means that the calls to eh.set.exception and eh.set.selector
are no longer needed here.  In fact the existing inliner logic for dealing
with "unwind" can be kept unaltered.

Ciao,

Duncan.



More information about the llvm-dev mailing list