Re: RFA: autoincrement patches for gcc 4 - updated patch

[Joern RENNECKE <joern dot rennecke at st dot com>]

As I have just posted to bugzilla:
 

bash-2.05b$ tail +4 ~/20050517-ppc-base-result-size.csv | awk 'FS="," {sum +=
$3} END {print sum }'
3511496
bash-2.05b$ tail +4 ~/20050517-ppc-orv-result-size.csv | awk 'FS="," {sum +=
$3} END {print sum }'
3514464
I.e. with the add_limits logic restored, we now see a 0.0845% code size
increase.
I think that can be explained by the fact that linking chains together
only works when we have non-zero add_limits, and the main point of linking
chains is to avoid reg-reg copies.  If a three-address add is available,
starting a new chain in a new register doesn't cost extra insns, if the
register allocation stays the same.  On the other hand, linking chains
together reduces the freedom of the register allocator.


So Bernd's concern about the impact on three-address machines was right.
The effect was masked before by code-rot.
So, since linking chains is specific for machines with two-address add, we
could either test if any three-address add is present, and not link chains
if there is, or we could calculate separate bounds for three-address adds,
and if a separate chain can't be set up with a three-address add, but we
can link one with a two-address add, do the chain linking.

The former solution would be simpler, but the latter would make sense if we
want optimize for processors which have a narrower, but still existant
constant range for three-address adds than for two-address adds.
Does anyone have some data and/or opinions on this?
 

------------------------------------------------------------------------