[LLVMdev] Alternative exception handling proposal

[John McCall]

On Dec 2, 2010, at 4:59 AM, Duncan Sands wrote:
>>> 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.

Well, remember, this optimization is only actually possible if there aren't any cleanups. :)

> It needs to be a codegen pass because only then do you know that the inliner
>  will not be run later.

Right, this is what I had in mind.

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

I agree — I personally prefer functional-style IRs to SSA, in part because they make it
relatively painless to introduce opaque values along special edges like this.  But
I don't think we'll be able to sneak that change into this redesign. :)

John.