Steven Bosscher wrote:
On 2/20/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
>[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.
I don't think it would be very useful to stabilize the trunk if that
can't be done in a matter of, say, two months. If it takes longer than
that, releasing gcc 4.2 as-is would be my choice. Yes, there is a SPEC
performance gap, but SPEC is not the one-benchmark-to-rule-them-all,
and there are things in the current gcc 4.2 release branch (such as
OpenMP, and a hugely improved GFortran) that I would like to see
released.
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).
Not releasing GCC 4.2 is IMHO not a really good option. If we do that,
GCC 4.3 will contain so much new code that the number of not yet
uncovered bugs that our users may run into, may be larger than we can
handle.
I am agree, we need a good release before making a big change as df
infrastructure.
