This is the mail archive of the
mailing list for the GCC project.
Re: PING for fwprop merge
I'm not really sure what's happening. It reminds me of the situation
with the tree-cleanup merge: the result do not seem that bad, OTOH they
do emphasize that the impact of fwprop on generated code is all but
trivial. We could now start all the old discussions on whether it is
appropriate to merge fwprop now, how the review was late, how merges
similar in spirit were committed by GWP people or maintainers, etc. etc.
If you still have some time to test on darwin and figure out what is
happening, then that would be great. Otherwise I guess we should
postpone fwprop to gcc 4.3.
Since everybody has spoken too much on these issues, I'll just summarize
the results. David sent them privately and asked not to disclose the
absolute numbers, so I'll just put some percentages. His results
sometimes showed oscillating numbers (two runs of the same benchmarks
with very different scores); in this case I compared the best result
from mainline with the best result from fwprop.
In SPECint we have a small overall improvement, with a notable -2% on
crafty and +8% on eon.
In SPECfp we have mostly very small improvements with standard options,
but -3% on lucas. Instead, there are indeed problems with -O3
-funroll-loops -ffast-math -fpeel-loops (-1.5% overall with -8% on mgrid
and -2% on lucas). However, with peak options many more benchmarks fail
(swim, applu, facerec, sixtrack) while galgel now passes; so the results
are not directly comparable.
In SPECint we have -9% on gap and +8% on eon.
In SPECfp we have -2.5% on mesa and -1.5% on applu, -1% on lucas with
standard options. With peak options instead we have +1% on applu but
-1.5% on apsi and -1% on lucas.
Since David Edelsohn reports that his old measurements were neutral, and
now they show pessimization, my guess is that the first committed patch
that stemmed out of the fwprop work has improved code for mainline.
This was committed last November, and was the change to store REG_EQUAL
notes in GCSE's hash table. That patch was meant to fix some problems
with removing CSE path following, which showed in PPC bzip2; however,
some improvement on PIC code was reported also for mainline (with path
following enabled) on s390, and it probably applies to PPC as well.
This could be interpreted as a point in favor of fwprop (if you consider
that patch was the "beginning" of the fwprop merge) or against (since
now mainline has indeed better performance). If possible, let's not
forget the 3% reduction in compile time.