Re: Loop unrolling-related SPEC regressions?

[Tim Prince <tprince@computer.org>]

On Tuesday 05 February 2002 04:29, Jan Hubicka wrote:
> > On Monday 04 February 2002 11:48, Andreas Jaeger wrote:
> > > Paolo Carlini <pcarlini@unitus.it> writes:
> > > > Jan Hubicka wrote:
> > > >> THe base/peak flags are not supposed to bring best performance,
> > > >> but be good for testing majority of gcc features.
> > > >
> > > > That's really enlightening Honza! Thanks for the clarification.
> > > > We should also remember this when someone compares the SPEC numbers
> > > > made available by other compiler producers with those of GCC: my
> > > > guess is that this kind of rationale for choosing the PEAK flags it's
> > > > unfortunately not so widespread...
> > >
> > > Didn't I mention it that way?  Feel free to send a patch for my SPEC
> > > page to clarify what we're doing...
> >
> > Of course, compilers which are sold on the basis of SPEC base performance
> > have different approach to default options than gcc.  One expects the
> > base option set to be the one which is the best single setting conforming
> > to the limit on number of options, to obtain the highest rating.  Thus, a
> > compiler such as Intel's makes a simple option package such as
> > 'icc -xW -Oi-'
> > roughly equivalent to
> > 'gcc -msse2 -march=pentium4 -Os -funroll-loops
> > -mpreferred-stack-boundary=4 -ffast-math'
>
> I am playing with the idea of making -O behaving like -f and allowing
> -Ospeed "optimize for maximal speed for common circmuatens" and -Osize.  We
> can also invent -O[no]debug "prohibit optimizations that make debugging
> dificult, like tail call optimization, frame pointer ellimination, or
> (currently) register renaming", or -Odangerous "enable language standard
> breaking transformations".
I thought that was the meaning of -ffast-math, or do you mean some 
combination of optimization which includes -ffast-math and -funroll-loops?
>
> Perhaps that can be usefull not only to "fit in" the spec2000 rules, but
> also to avoid confusion of users. Many benchmarks published uses far from
> "sane" compilation switches.
Yes, there is a need for a simple switch which includes most "sane" 
optimizations which are useful for a specified architecture, even if it is 
not quite sufficient for a good SPEC score. 
>
> Honza
>
> > with even the base rating depending on Profile Guided Optimization.
> > Of course, one expects the peak rating to be found with a set of options
> > which produces the fastest acceptable result for each test, not
> > necessarily the most aggressive group of optimizations.  In that light,
> > the SPEC disclosures allow one to speculate as to how much trial and
> > error work was needed to obtain the results submitted, and how much more
> > might be needed to achieve equivalent performance on a typical
> > application.
> >
> > I thank Andreas and Honza for explaining the difference between what they
> > have done and what some of us may have expected.