llvm dev - Dec 2010 - [LLVMdev] Inlining and exception handling in LLVM and GCC

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.

On 8 December 2010 14:07, Duncan Sands <baldrick at free.fr>
wrote:
> 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,
I see, in that case, it makes more sense to attach all the information
to the callee block rather than force the artificial association of a
dispatch instruction with a particular basic block.

If I'm not yet as lost as I think I am, that's your proposal, right?

Sorry for being so redundant, is that I stopped reading the thread
after a while but I still think it's an important proposal to get it
right this time.

-- 
cheers,
--renato

http://systemcall.org/

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm

On 8 December 2010 14:21, Renato Golin <rengolin at systemcall.org>
wrote:
> I see, in that case, it makes more sense to attach all the information
> to the callee block rather than force the artificial association of a
> dispatch instruction with a particular basic block.
Sorry, I meant "caller" block.

--renato

Hi Renato,
> On 8 December 2010 14:07, Duncan Sands<baldrick at free.fr>  wrote:
>>   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,
>
> I see, in that case, it makes more sense to attach all the information
> to the callee block rather than force the artificial association of a
> dispatch instruction with a particular basic block.
>
> If I'm not yet as lost as I think I am, that's your proposal,
right?
yes, that's it: don't store info about catches in eh.selector calls,
just attach
it directly to the basic block in which the exception is raised (which right now
means the one containing the invoke).  Most of my proposal was a long-winded
explanation of why this actually solves a bunch of problems, but the content of
the proposal is one line long, as proved by the previous line :)

Ciao, Duncan.