This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PING for fwprop merge



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.
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. etc.

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.

For 32-bit:

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.

---

For 32/64-bit:

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.

Paolo


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]