This is the mail archive of the gcc@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: changing "configure" to default to "gcc -g -O2 -fwrapv ..."


On 12/31/06, Richard Guenther <richard.guenther@gmail.com> wrote:
On 12/31/06, Daniel Berlin <dberlin@dberlin.org> wrote:
> On 12/31/06, Paul Eggert <eggert@cs.ucla.edu> wrote:
> > "Steven Bosscher" <stevenb.gcc@gmail.com> writes:
> >
> > > On 12/31/06, Paul Eggert <eggert@cs.ucla.edu> wrote:
> > >> Also, as I understand it this change shouldn't affect gcc's
> > >> SPEC benchmark scores, since they're typically done with -O3
> > >> or better.
> > >
> > > It's not all about benchmark scores.
> >
> > But so far, benchmark scores are the only scores given by the people
> > who oppose having -O2 imply -fwrapv.  If the benchmarks use -O3 they
> > wouldn't be affected by such a change -- and if so, we have zero hard
> > evidence of any real harm being caused by having -O2 imply -fwrapv.
> >
> > > I think most users compile at -O2
> >
> > Yes, which is why there's so much argument about what -O2 should do....
> >
> > > You say you doubt it affects performance.  Based on what?  Facts
> > > please, not guesses and hand-waiving...
> >
> > The burden of proof ought to be on the guys proposing -O2
> > optimizations that break longstanding code, not on the skeptics.
>
> The burden ought to be (and IMHO is) on those who propose we change
> optimizer behavior in order to support something non-standard.
>
> Why do you believe otherwise?
> >
> > That being said, I just compiled GNU coreutils CVS on a Debian stable
> > x86 (2.4 GHz Pentium 4) using GCC 4.1.1.  With -O0, "sha512sum" on the
> > coreutils tar.gz file took 0.94 user CPU seconds (measured by "time
> > src/sha512sum coreutils-6.7-dirty.tar.gz").  With -O2 -fwrapv, 0.87
> > seconds.  With plain -O2, 0.86 seconds.
> >
> > I also tried gzip 1.3.10, compressing its own tar file with a -9
> > compression option.  With -O0, 0.30 user CPU seconds.  With -O2
> > -fwrapv, 0.24 seconds.  With -O2, 0.24 seconds.
> >
> > In all these cases I've averaged several results.  The difference
> > between -O2 and -O2 -fwrapv is pretty much in the noise here.
> >
> > Admittedly it's only two small tests, and it's with 4.1.1.  But that's
> > two more tests than the -fwrapv naysayers have done, on
> > bread-and-butter applications like coreutils or gzip or Emacs (or GCC
> > itself, for that matter).
>
> These are not performance needing applications.
> I'll happily grant you that  adding -fwrapv will make no difference at
> all on any application that does not demand performance in integer or
> floating point calculations.

I added -fwrapv to the Dec30 run of SPEC at
http://www.suse.de/~gcctest/SPEC/CFP/sb-vangelis-head-64/recent.html
and
http://www.suse.de/~gcctest/SPEC/CINT/sb-vangelis-head-64/recent.html


Note the distinct drop in performance across almost all the benchmarks on Dec 30, including popular programs like bzip2 and gzip.


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