GCC 4.2.0 Status Report (2007-02-19)

Vladimir Makarov vmakarov@redhat.com
Tue Feb 20 19:42:00 GMT 2007


Paolo Bonzini wrote:

>
>> I am agree, benchmarking is evil.  My favorite benchmark is gcc 
>> because it is my tool and I work on it.  Compilation of gcc from 
>> Spec2000 is  >12% slower with df including last Paolo's patches 
>> (which are a really big improvement).
>
>
> Interesting enough, 176.gcc has a pretty bad result for runtime too in 
> SPEC2000:
>
> 176.gcc          1100      67.8      1622      1100      72.9      1509*
> 176.gcc          1100      68.1      1614*     1100      72.9      1509
> 176.gcc          1100      68.8      1600      1100      72.6      1515
>
>
> By your reasoning, there is some probability that fixing this one 
> performance regression brings dataflow branch into shape for merging 
> into mainline... (even though so much has changed since 2.7.2 which is 
> used in SPEC2000).
>
Usually I check code size fo x86/x86_64.  If it is bigger then something 
is going wrong (it might be not true for itanium).  It means more insns 
(and probably performance degradation) and more compile time to process 
insns (but i think for df generation more insns is only part of 
slowdown).  For df gcc code size is 0.5% bigger.

I'd like to use spec2006 gcc (as I remeber it is gcc 3.4) but running 
spec20006 takes so long time for now.  Still gcc-2.7 is good test for 
big functions, switches etc.  It is still a characteristic of modern gcc 
versions.




More information about the Gcc mailing list