[LLVMdev] Alternative exception handling proposal

[Duncan Sands]

Hi John,

>> 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.
>
> Okay, this is at least workable, and it has the advantage of requiring less invasive
> changes to IR structure.  It has the disadvantage of requiring us to emit a cleanup
> path for every handling scope, which is a code size pessimization, but catches are
> rare relative to cleanups, so that's probably not a problem in practice — and
> it should be easy to optimize if we really care, since by definition we're talking
> about a landing pad which doesn't do anything interesting before it tests the selector
> value.

in Ada cleanups come after handlers, so it's a bit trickier, but yes in theory
the code generators could try to remove pointless code of this kind.  It needs
to be a codegen pass because only then do you know that the inliner will not be
run later.

> I haven't really thought about how to actually make the data flow correctly, though,
> so I might let you and Bill fight out the best representation.

I don't much like eh.exception myself - the exception value should really be an
argument for the landing pad somehow.  That would make it impossible to use
wrong, unlike now where front-ends have to be careful to call eh.exception in
each landing pad and stash the value in a variable.  In practice that's not a
problem (for example unlike with the catch info the optimizers will never create
problems) but it shows that eh.exception is not a good abstraction.  But to some
extent this is orthogonal to how catch info is handled.

Ciao,

Duncan.