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.
