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

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.

On Dec 8, 2010, at 6:31 AM, Duncan Sands wrote:
> 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.
I do not know EH or details of these proposals. But do not forget, basic blocks
are merged/split/deleted, instructions are added/removed/moved/copied/replaced.
-
Devang
>> 
>> 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 :)

On 8 December 2010 18:45, Devang Patel <dpatel at apple.com>
wrote:
> I do not know EH or details of these proposals. But do not forget, basic
blocks are merged/split/deleted, instructions are
added/removed/moved/copied/replaced.
Indeed. Having the information in the invoke kinda alleviates this
problem, but removing the invoke syntax will bring that back.

One way to merge two basic blocks is to split into several smaller
basic blocks with same properties and then branch to and from that new
sub-block instead of actually moving the instructions inside the
merged block.

I don't know the effects of block fragmentation in LLVM, but that
would definitely increase it. But having EH info in every instruction
is also too much... :/

cheers,
--renato