Re: -march=i686 on i686 ?!?

["Tim Prince" <tprince at computer dot org>]

----- Original Message -----
From: "Paolo Carlini" <pcarlini@unitus.it>
To: <gcc@gcc.gnu.org>
Cc: <dnovillo@redhat.com>
Sent: Tuesday, July 03, 2001 11:06 AM
Subject: -march=i686 on i686 ?!?


> Hi all,
>
> lately I started bothering the list about my own strange benchmarking
> issues...
>
> This one my perhaps interest a few more people: when exactly specifying
> -march=i686 (on a i686) is supposed to lead to appreciably better
> performing code?
>
> In my personal experience (unexpectedly) many of the widespread short
> benchmarks do not improve when -march=i686 is added to the command line.
> But this is not very relevant. What is more relevant, I think, is that
> also many reported benchmarks results for x86 are obtained with the -O2
> or -O3 switches and do not discuss at all the particular x86
> architecture. This seems strange to me...
>
> Could someone in the known, explain a little bit of this?? I think may
> be of interest to many users.
>
> Thanks,
> Paolo.
>
Here are a few possible explanations:

1.  People run benchmarks with one set of compiler flags, which may or may not have been appropriate for some combination of
hardware and gcc version at one time.  They tend not to adapt to changes in compilers which would make new choices desirable.

2.  There was breakage in -march=pentiumpro -ffast-math until recently, and there may still be problems with gcc versions supplied
with software which many people are running.   It's not easy for people to understand that -Os is usually best for P-II and P-III,
where -O3 may be appropriate for P4 or non-Intel targets, or that proper alignments are not set on many targets because of backward
compatibility problems with g++ libraries.  People used to commercial compilers may not understand that -funroll-loops is a normal
optimization which is not implied by any other.  Then, because of the way the optimizations are treated by glibc on many linux
systems, it is not easy to get the benefits of the best gcc options.

3. gcc has to support many different architectures; even if it were primarily oriented toward IA32, the example of commercial
compilers doesn't hold much hope for making the best options for your hardware happen by default.  I was experimenting today on this
P-III recycled from the repair depot, finding that 16-byte data alignments are quite important in certain situations, which I
wouldn't have found if I didn't know what to look for.  I still find un-explained performance regressions with new versions of every
compiler, not only gcc.

4. Where there are public disclosures on SPEC Cpu2000, the options used may give useful information, but it may be that no one has
run these with gcc until recently, and the gcc results are not AFAIK in the usual SPEC pages.  SPEC is not well aligned with the
open software way, and they may even discourage people who have such information from making it public.  Certainly, those people who
are running SPEC on their employers' time may be restricted from publicizing results.  In order to get good SPEC results according
to the rules, it might be necessary to have specific option packages for each variation of hardware, so that a single option implies
a useful combination for that hardware.  Fortunately, gcc is not so driven by SPEC as are many commercial compilers.