This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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 }'
bash-2.05b$ tail +4 ~/20050517-ppc-orv-result-size.csv | awk 'FS="," {sum +=
$3} END {print sum }'
I.e. with the add_limits logic restored, we now see a 0.0845% code size
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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]