[LLVMdev] Inlining and exception handling in LLVM and GCC

[Duncan Sands]

Hi Renato,

>>>    1. It eases the future elimination of invoke, or at least, the
>>> treatment of current instruction-level exception (as in Java) in a
>>> cleaner way.
>>
>> I don't see what is cleaner about it, except that it is overall at a higher
>> level of abstraction (see above).
>
> If I got it right, his proposal had the unwind path in the basic block
> (rather than in the invoke), so any instructions in that basic block
> (including simple calls, without the nounwind attribute) would use
> that as the landing pad.
>
> That would make invokes obsolete.

I think you took my proposal too literally :)  It's irrelevant to the idea of it
whether catch info is attached to an invoke or to a basic block.  I showed it
attached to invokes to make the proposal more concrete.  If we are going to
change the IR then we should try to change it in such a way that we don't have
to change it again when we remove the invoke instruction.  This means that if I
start coding my proposal then almost certainly I will attach the info to basic
blocks.  In fact it makes sense to do so even before we remove the invoke
instruction: in the short term we would still have invoke, but the catch info
for the invoke would be attached to the basic block containing the invoke,
which is equivalent to attaching it to the invoke.  One day we will remove
invoke, and the info will already be in the right spot (on the basic block).

Ciao, Duncan.