Re: block movement and eh

[Andrew Macleod <amacleod at cygnus dot com>]

>> > Makes sense to me.  In fact, HP's proposal for ia64 EH involves using a
>> > table of EH PC values (i.e. the call sites), rather than ranges.
>> 
>> Hmm.  I wonder if we could do something like that, at least for
>> internal representation, now.  Correct me if I'm wrong:

I was wondering the same thing when I read the original note.

>> The REG_EH_REGION note indicates what region a call can throw to.
>> We make an initial pass over the rtl, annotate all of the calls
>> that don't already have such notes.  We then delete all of the
>> NOTE_INSN_EH_REGION notes, and don't have to worry about regions
>> at all for the rest of compilation.
>> 

We have to leave the NOTES in for asynchronous exceptions, or mark the
end of a region somehow. It does simplify the normal case quite
a bit however.. 

>> Just before (or during) final, we find the maximum span of calls
>> that have compatible region notes (the same region or 0 or -1 but
>> not no note) and re-create NOTE_INSN_EH_REGION notes.
>> 
>> 

Thats slightly better than what I was thinking actually. I wasn't
thinking about recreating the notes, just figuring the span and emitting the
table. But then you needed the current mechanism for asynchronous
exceptions. By recreating the NOTES, both are the same since you 
the NOTEs are in place.

  I think this would also allow us to produce more efficient tables, as
long as the NOTE recreation routine is good. This would be an interesting
algorithm. hmm, IF we move a few blocks around, a region may not be 
contiguous any more, and require more than 1 entry in the table. 
ie

     b1(5)
    /   \
  b2(5)  b3(6)
   |    /  \
   |  b4(7) b5 (6)
   |    \   /
  b7(5)  b6(6)
   \     /
    \   /
     b8(5)

Given these 3 regions, and basic block b4 being the fallthrough from
b3, some block reordering alogithm might decide to move block b5 to the
end of the function, or somewhere else.
Then the code sequence would look like:


b1 region 5 -+
b2 region 5  |
b3 region 6  |      -+
b4 region 7  |       |        ==
b6 region 6  |      -+
b7 region 5  |
b8 region 5 -+
b5 region 6         ==

Now region 6 is going to require 2 range entries instead of one. not that
this matters that much, the non-exception code should run faster,
but it is the kind of circumstance we do need to be aware of. 
It will get rid of any unneeded regions more easily than my current
approach.

I think its a good idea, but maximum span of a region alone wont 
be enough. Maybe we can track what region is active at the start and end of 
each basic block, figure out which pred/succ blocks are in the same
region, and insert notes that way somehow... 

I have to think about whether this works properly for rethrowing... hmm.

Andrew