Re: GCC 4.2.0 Status Report (2007-02-19)

[Vladimir Makarov <vmakarov at redhat dot com>]

Mark Mitchell wrote:

> I've spent some time today looking at GCC 4.2.
>
> I've heard various comments about whether or not it's worth doing a 4.2
> release at all.  For example:
>
> [Option 1] Instead of 4.2, we should backport some functionality from
> 4.2 to the 4.1 branch, and call that 4.2.
>
> [Option 2] Instead of 4.2, we should skip 4.2, stabilize 4.3, and call
> that 4.2.
>
> [Option 3] Like (2), but create (the new) 4.2 branch before merging the
> dataflow code.
>
>
>  
...

> Considering the options above:
>
> * I think [Option 3] is unfair to Kenny, Songbae, and others who have
> worked on dataflow code.  The SC set criteria for that merge and a
> timeline to do the merge, and I believe that the dataflow code has met,
> or has nearly met, those criteria.
>  
In term of ports, yes I am agree.  As the preformance even with last 
Paolo's patches (some changes could be applied to the mainline too, so 
it is not only about df), the branch compiler is still 8.7% slower for 
SPECint2000 compilation on 2.66Ghz Core2 with --enable-check=release.

> So, my feeling is that the best course of action is to set a relatively
> low threshold for GCC 4.2.0 and target 4.2.0 RC1 soon: say, March 10th.
>      Then, we'll have a 4.2.0 release by (worst case, and allowing for
> lameness on my part) March 31.
>
> Feedback and alternative suggestions are welcome, of course.
>
>  
I like option 3.  Gcc 4.2 has a pretty big degradation in performance. 
Thanks to Intel guys for reporting Spec2006 results.  That is a really 
serious degradation.  I know how difficult to get 1% improvement 
especially for SPEC2006.  So losing 10-25% (and I guess code size) makes 
gcc4.2 a really bad version.  IMHO, it would be a mistake to use it 
without change for any distribution.

Option 3 gives dataflow guys more time to polish it and maintainers for 
ports missed in the merge criteria to fix possible problems.  Again I am 
not against dataflow infrastructure even with its currrent fat data 
structures.  Actually it has been existing for long time on mainline in 
some form and is used for many optimizations.  The next logical step 
would be rewriting more RTL optimizations to df infrastructure and I am 
not sure that the current state of df will make gcc faster.

As for proposal to revert the aliasing fixes on the 4.2, IMHO aliasing 
bugs are pretty nasty it is hard to find a option to work around because 
alias info is used in many optimizations.