gcc 3.4.1 and CPU optimization

gcc 3.4.1 and CPU optimization

[Zbigniew Łuszpiński]

Helo!

I compile many programs from sources. A lot of them have optimizations like 
-m386, -mcpu=486, -mtune=i686, -march=i686 or other.
I use AMD AthlonXP 2500+. Everytime I compile program first do ./configure 
CFLAGS="-march=athlon-xp". Could you tell me which one optimization will be 
used? These hardcoded into configure script or this one provided by me with 
CFLAGS parameter ?

What will happen when gcc will get -march=i586 from script and 
-march=athlon-xp from me?

Which optimization will be used when some of them are placed together? e.g. 
-mtune=pentium -march=athlon-xp.

greetings,
Zbigniew

Re: gcc 3.4.1 and CPU optimization

[Ian Lance Taylor]

Zbigniew Łuszpiński <zbiggy@o2.pl> writes:

> I compile many programs from sources. A lot of them have optimizations like 
> -m386, -mcpu=486, -mtune=i686, -march=i686 or other.
> I use AMD AthlonXP 2500+. Everytime I compile program first do ./configure 
> CFLAGS="-march=athlon-xp". Could you tell me which one optimization will be 
> used? These hardcoded into configure script or this one provided by me with 
> CFLAGS parameter ?

The one which is used when the compiler is run.  In typical cases this
will be the one specified as the CFLAGS parameter when you run
configure, but you should check the actual compilation lines to be
sure.

> What will happen when gcc will get -march=i586 from script and 
> -march=athlon-xp from me?

gcc will use the one which appears last on the gcc command line.

> Which optimization will be used when some of them are placed together? e.g. 
> -mtune=pentium -march=athlon-xp.

In a case like that both will be used.  The -march option controls the
generated instruction set.  The -mtune option controls the tuning,
which affects instruction selection (among supported instructions) and
scheduling.

When two -mtune or -march options are used, the one which appears last
on the command line takes precedence.

Ian

Re: gcc 3.4.1 and CPU optimization

[Zbigniew Łuszpiński]

Helo!

I read very carefully gcc docs and some infos on the net.
Old -mcpu= -m386 -m486 -pentium -mpentiumpro are repalced by new -mtune=
The -mmx -msse -m3dnow are included in -march=
The -mtune is included in -march=
So -march= have all optimizations included.
Every next option provided in commandline overwrites the one used before (e.g. 
if specified -march=i586 -march=athlon-xp compilation will be made for 
athlon-xp).
The ./configure CFLAGS="-march=athlon-xp" places -march=athlon-xp at the end 
of gcc parameter list so all optimizations used before are overwritten by 
-march=athlon-xp.

Is it true or my pure imagination?
If script generated -march=i586 -mtune=i686 and I add 
CFLAGS="-march=athlon-xp" parameter, the compilation will be for athlon-xp 
and -mtune=i686 will not be used?

greetings,
Zbigniew

Re: gcc 3.4.1 and CPU optimization

[Nix]

On 1 Dec 2004, Zbigniew mused:
> The renaming gcc by aliasing it is necessary. Since someone told me 
> about ./configure CFLAGS="option" I was manually editing houndreds of config 
> lines (many programs were compiled) to have good optimization. If you 
> recompile many programs to speed up system a little you will understand what 
> I am talking about.

This is what site-config files are for.

e.g.

CONFIG_SITE="/some/shell/script"

where /some/shell/script contains e.g.

[ "x$CFLAGS" = "x" ] && CFLAGS="-O2 -march=athlon-4"
[ "x$CXXFLAGS" = "x" ] && CXXFLAGS="-O2 -fpermissive -march=athlon-4"

site-config scripts are run before the configure script proper runs, so
all you have to deal with is configure scripts which *override* the
user's choice of CFLAGS. Such are, as I said, comparatively rare.


The major advantage of this approach over a config file is that the
site-config script can be arbitrarily complicated. Mine's been growing
for a decade and now puts together a set of optimization flags and the
names of compilers taking into account per-application configuration
files, possible cross-compilation, and much else.

Plus, a site-config script can turn on and off other configure flags,
too, if it's sufficiently evil. There's no way you can do *that* even
with a script wrapping config files.

With a bit of effort you can make this apply to programs that don't use
Autoconf-based configure scripts, too: I use a makefile fragment that
executes the same low-level code that the site-config script executes to
determine compilation flags, then translates it into Makefile rules,
redirects that to a file and includes the file: a two-line addition to
most makefiles will make that `site-config makefile fragment' apply to
them.


The upshot is that it is already easy to set site policy regarding
configuration flags, there are multiple possible mechanisms, most of
which have a full programming language available to compose command
lines. There's no need to put this stuff into GCC.

-- 
`The sword we forged has turned upon us
 Only now, at the end of all things do we see
 The lamp-bearer dies; only the lamp burns on.'

Re: gcc 3.4.1 and CPU optimization

[Zbigniew Łuszpiński]

Orginal message
> On Wed, Dec 01, 2004 at 06:35:08PM +0100, Zbigniew ?uszpi?ski wrote:
> > Remember that default settings are always overwritten by those 
> > set in command line (by script or user). The aim of this discussion is to 
> > create default gcc configuration which can not be replaced by parameters 
> > executed from commandline.
> 
> I would oppose such an approach in the official gcc, as it makes the
> compiler more difficult to support.  People will then report bugs that we
> can't reproduce, because they are unaware of the settings in a hidden
> configuration file.

This file should be an option for power users. All of its content should be 
commented out by default. The power users would delete comment # signs to 
enable options they need. In such way the rest of gcc users will be safe.

I have new idea about this issue. gcc should have new option: 
-use-current-cpu. This option should have higher priority than other to stop 
optimization chaos. The gcc could detect current processor by looking 
in: /proc/cpuinfo file.
There are some advatanges:
+ old scripts will not be broken because they do not know new option
+ it is easy to support in new scripts
+ the faulty configure processor detection procedure could be removed from 
make scripts
+ it is easy to support in old configure scripts via adding 
CFLAGS="-use-current-cpu" to configure in commandline. Thanks to this gcc 
will silently clean up its commandline parameters by ignoring old 
optimization parameters.
+ it is easier to update gcc processor recognize engine than updating million 
configure scripts laying around Internet.

> > Ali Imran have good idea how to resolve this problem. I probably end up
> > with bash script aliased to gcc which will filter out deprecated
> > options, add mine and pass it to orginal gcc renamed to gcc.orginal.
> 
> This is the best approach; even better would be to avoid renaming gcc,
> and calling your script gcc-zbigniew or something, so that people who
> run it are constantly aware that they are not running the actual gcc.
> After all, you appear to want to either reject or silently discard some
> options, and add other options that the user did not select.
> With proper Makefiles, you can change the compiler just by specifying
> the value of one variable (CC).
> 

The renaming gcc by aliasing it is necessary. Since someone told me 
about ./configure CFLAGS="option" I was manually editing houndreds of config 
lines (many programs were compiled) to have good optimization. If you 
recompile many programs to speed up system a little you will understand what 
I am talking about.
If I setup gcc to run with -march=athlon-xp option it would be good to reject 
or silently discard bad optimizations from scripts like -m386 or 
-mtune=pentium. It is sad that I have to clean chaos made by someone else.

greetings,
Zbigniew

Re: gcc 3.4.1 and CPU optimization

[Joe Buck]

On Wed, Dec 01, 2004 at 06:35:08PM +0100, Zbigniew ?uszpi?ski wrote:
> Remember that default settings are always overwritten by those 
> set in command line (by script or user). The aim of this discussion is to 
> create default gcc configuration which can not be replaced by parameters 
> executed from commandline.

I would oppose such an approach in the official gcc, as it makes the
compiler more difficult to support.  People will then report bugs that we
can't reproduce, because they are unaware of the settings in a hidden
configuration file.

> Ali Imran have good idea how to resolve this problem. I probably end up
> with bash script aliased to gcc which will filter out deprecated
> options, add mine and pass it to orginal gcc renamed to gcc.orginal.

This is the best approach; even better would be to avoid renaming gcc,
and calling your script gcc-zbigniew or something, so that people who
run it are constantly aware that they are not running the actual gcc.
After all, you appear to want to either reject or silently discard some
options, and add other options that the user did not select.
With proper Makefiles, you can change the compiler just by specifying
the value of one variable (CC).

Re: gcc 3.4.1 and CPU optimization

[Zbigniew Łuszpiński]

Orginal message
> Zbigniew Łuszpiński <zbiggy@o2.pl> writes:
> 
> > I have idea how to solve this problem. We can not fix all the scripts on 
this 
> > planet. So gcc should be fixed. I think that future version of gcc should 
> > have a new configuration file. For example gcc.permanent.conf. In this 
file 
> > an user could setup and configure all the user's default settings which 
> > should be used instead of those from command line (which are created by 
> > script or user). Options in such file have the highest priority and 
> > overwrites these one provided via command line. Such file could clean up 
> > parameters chaos made by scripts and users.
> 
> Current versions of gcc already support options to the configure
> script which can do this: --with-cpu, --with-arch, --with-tune.  This
> set the defaults for a particular configuration of gcc.  These are
> documented here:
>     http://gcc.gnu.org/install/configure.html
> 
> Ian
> 
This is useful only for building gcc itself and compiling programs without 
parameters. Remember that default settings are always overwritten by those 
set in command line (by script or user). The aim of this discussion is to 
create default gcc configuration which can not be replaced by parameters 
executed from commandline.

Ali Imran have good idea how to resolve this problem. I probably end up with 
bash script aliased to gcc which will filter out deprecated options, add mine 
and pass it to orginal gcc renamed to gcc.orginal. In my opinion the gcc 
should clean up this parameters chaos. I think that other programmers, 
administrators, power users also will meet this problem, like me now. So 
everybody will write own filtering script ?

greetings,
Zbigniew

Re: gcc 3.4.1 and CPU optimization

[Ian Lance Taylor]

Zbigniew Łuszpiński <zbiggy@o2.pl> writes:

> I have idea how to solve this problem. We can not fix all the scripts on this 
> planet. So gcc should be fixed. I think that future version of gcc should 
> have a new configuration file. For example gcc.permanent.conf. In this file 
> an user could setup and configure all the user's default settings which 
> should be used instead of those from command line (which are created by 
> script or user). Options in such file have the highest priority and 
> overwrites these one provided via command line. Such file could clean up 
> parameters chaos made by scripts and users.

Current versions of gcc already support options to the configure
script which can do this: --with-cpu, --with-arch, --with-tune.  This
set the defaults for a particular configuration of gcc.  These are
documented here:
    http://gcc.gnu.org/install/configure.html

Ian

Re: gcc 3.4.1 and CPU optimization

[Zbigniew Łuszpiński]

Orginal message

Big thanks for help.

> (By the way, this is off-topic on this list, which is for discussing the
> development *of* GCC. The gcc-help@gcc.gnu.org list is the one to use for
> questions about development *with* GCC.)
> 

Yes I know the aim of this list. My opening e-mail was not only made to find 
answer to my question but also to show some difficulties when compliling 
programs with gcc. That is why I send it to you, developers of gcc.

I have idea how to solve this problem. We can not fix all the scripts on this 
planet. So gcc should be fixed. I think that future version of gcc should 
have a new configuration file. For example gcc.permanent.conf. In this file 
an user could setup and configure all the user's default settings which 
should be used instead of those from command line (which are created by 
script or user). Options in such file have the highest priority and 
overwrites these one provided via command line. Such file could clean up 
parameters chaos made by scripts and users.

gcc.permanent.conf example (and proposal)
===
# This is example of new gcc.permanent.conf file. Thanks to its power you will 
# never have troubles with gcc parameters chaos
# Options with x mark are disabled
# Options without x mark are enabled
# example:
#   -enabled
# x-disabled
# The unusual x disable mark is provided to not brake syntax of gcc

# Enable specific optimization
-march=athlon-xp #enable  compilation of programs for athlon-xp

#Disable all deprecated options still active in old scripts
x-m* # disable old optimization e.g. -m386, -m486
x-mcpu # disable because -march option is in use
x-mtune # disable because -march option is in use
# End of example

This is only an idea how to solve gcc parameters confusion. It is open for 
discussion, comments, modifications, ignoring, etc.

greetings,
Zbigniew

Re: gcc 3.4.1 and CPU optimization

[Nix]

On 30 Nov 2004, Zbigniew said:
> I compile many programs from sources. A lot of them have optimizations like 
> -m386, -mcpu=486, -mtune=i686, -march=i686 or other.
> I use AMD AthlonXP 2500+. Everytime I compile program first do ./configure 
> CFLAGS="-march=athlon-xp". Could you tell me which one optimization will be 
> used? These hardcoded into configure script or this one provided by me with 
> CFLAGS parameter ?

If the configure script conforms to the GNU Coding Standards, the one you
provide will take precedence.

In my experience, about 10% of configure scripts don't conform; these need
to be fixed (normally a trivial job).

> What will happen when gcc will get -march=i586 from script and 
> -march=athlon-xp from me?

That depends, but the configure script *should* choose to pass GCC only
the one you chose, not the configure script's choice. (This is not GCC's
concern: it doesn't know where its command-line options came from!)

> Which optimization will be used when some of them are placed together? e.g. 
> -mtune=pentium -march=athlon-xp.

Later command-line options override earlier ones, so whichever comes
last on the command-line will be used.


(By the way, this is off-topic on this list, which is for discussing the
development *of* GCC. The gcc-help@gcc.gnu.org list is the one to use for
questions about development *with* GCC.)

-- 
`The sword we forged has turned upon us
 Only now, at the end of all things do we see
 The lamp-bearer dies; only the lamp burns on.'

gcc 3.4.1 and CPU optimization

[Zbigniew Łuszpiński]

Helo!

I compile many programs from sources. A lot of them have optimizations like 
-m386, -mcpu=486, -mtune=i686, -march=i686 or other.
I use AMD AthlonXP 2500+. Everytime I compile program first do ./configure 
CFLAGS="-march=athlon-xp". Could you tell me which one optimization will be 
used? These hardcoded into configure script or this one provided by me with 
CFLAGS parameter ?

What will happen when gcc will get -march=i586 from script and 
-march=athlon-xp from me?

Which optimization will be used when some of them are placed together? e.g. 
-mtune=pentium -march=athlon-xp.

greetings,
Zbigniew