Optimizations

Optimizations

[David M. Ronis]

There's been some disccussion of egs vs gcc vs MSC benchmark results
on comp.os.linux.development.apps recently, much of which ends up with
various suggestions of what compiler flags should be specified.  For
example, one poster suggests:

gcc -O6 -mpentium -fomit-frame-pointer -fexpensive-optimizations \
>-ffast-math

To that, add:
        -march=pentium
        -fschedule-insns
        -fschedule-insns2
        -fregmove
        -fdelayed-branch

According to the gcc info description, all the -f options are enabled
(if supported) when -O2 (and I presume -O6) is specified.  Is this
correct?  

To the above I normally add the following:

-malign-double -malign-loops=0 -malign-jumps=0 -malign-functions=0\
-mno-ieee-fp 

Are the -malign directives implied by -march=pentium? (they probably
should be, and in either case, this sould be described in the info
pages).

Is -mno-ieee-fp implied by -ffast-math?


David Ronis

Re: Optimizations

[Jeffrey A Law]

  In message < 199712091751.MAA18879@ronispc.chem.mcgill.ca >you write:
  > gcc -O6 -mpentium -fomit-frame-pointer -fexpensive-optimizations \
  > >-ffast-math
-fexpensive-optimizations is on automatically if you specify -O2 or
higher.

Similarly for -fregmove.

-fdelayed-branch does nothing on x86 machines since they do not have
delayed branches.

-fschedule-insns* are normally enabled for -O2 or higher.

  > Is -mno-ieee-fp implied by -ffast-math?
No.  -ffast-math is a machine independent option while -mno-ieee-fp is
an x86 specific option.  They are separate.

jeff

Re: [EGCS] Optimizations

[Marc Lehmann]

> gcc -O6 -mpentium -fomit-frame-pointer -fexpensive-optimizations \
> >-ffast-math
> 
> To that, add:
>         -march=pentium
>         -fschedule-insns
>         -fschedule-insns2
>         -fregmove
>         -fdelayed-branch
> 
> According to the gcc info description, all the -f options are enabled
> (if supported) when -O2 (and I presume -O6) is specified.  Is this
> correct?  

no, you misread the info files. almost everything
except -finline-functions and -fomit-frame-pointer is enabled at -O2,
-O3 enables -finline-functions.

-fschedule-insns is a *loss* on x86 cpu's!

> -malign-double -malign-loops=0 -malign-jumps=0 -malign-functions=0\
> -mno-ieee-fp 
> 
> Are the -malign directives implied by -march=pentium? (they probably

on pgcc, yes, on egcs, no. the mno-ieee-fp is a bit buggy.

the -mpentium should be selected automatically when you compile
for i586-*-*, but I'm not exactly sure here.

> Is -mno-ieee-fp implied by -ffast-math?

no.

      -----==-                                              |
      ----==-- _                                            |
      ---==---(_)__  __ ____  __       Marc Lehmann       +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com       |e|
      -=====/_/_//_/\_,_/ /_/\_\                          --+
    The choice of a GNU generation                        |
                                                          |

Re: [EGCS] Optimizations

[Philipp Thomas]

Marc Lehmann wrote:
> -fschedule-insns is a *loss* on x86 cpu's!

care to explain why it is a loss (and most probably also -fschedule-insns2)
?


-- 
Philipp

************************************************************
 If builders would build houses like programmers did       
 their programs, the first woodpecker to come along would
 mean the end of all civilization

Re: Optimizations

[Marc Lehmann]

On Sun, Dec 14, 1997 at 02:34:36PM +0100, Philipp Thomas wrote:
> Marc Lehmann wrote:
> > -fschedule-insns is a *loss* on x86 cpu's!
> 
> care to explain why it is a loss (and most probably also -fschedule-insns2)
> ?

AFAIR -fschedule-insns (as opposed to -fschedule-insns2) is normally a loss
sicne the first scheduling pass is done before register allocation, so the
register pressure increases and local/global get's problems. (for fpu code
it _could_ be beneficial, though).

the second scheduling pass is done after register allocation, so no
"new" hardware registers are created.

      -----==-                                              |
      ----==-- _                                            |
      ---==---(_)__  __ ____  __       Marc Lehmann       +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com       |e|
      -=====/_/_//_/\_,_/ /_/\_\                          --+
    The choice of a GNU generation                        |
                                                          |

Re: Optimizations

[Jeffrey A Law]

  In message < 19971215000809.60319@cerebro.laendle >you write:
  > On Sun, Dec 14, 1997 at 02:34:36PM +0100, Philipp Thomas wrote:
  > > Marc Lehmann wrote:
  > > > -fschedule-insns is a *loss* on x86 cpu's!
  > > 
  > > care to explain why it is a loss (and most probably also -fschedule-insns
  > 2)
  > > ?
  > 
  > AFAIR -fschedule-insns (as opposed to -fschedule-insns2) is normally a loss
  > sicne the first scheduling pass is done before register allocation, so the
  > register pressure increases and local/global get's problems. (for fpu code
  > it _could_ be beneficial, though).
To be more correct it may be a loss for machines with a limited number of
registers (such as the x86).  On machines with a generous number of registers
-fschedule-insns is generally a win.

jeff

Re: [EGCS] Optimizations

[meissner]

| Marc Lehmann wrote:
| > -fschedule-insns is a *loss* on x86 cpu's!
| 
| care to explain why it is a loss (and most probably also -fschedule-insns2)

The problem is that -fschedule-insns, -funroll-{,all-}loops, and
-fstrength-reduce all tend to work by creating more registers to hold
intermediate results (in compiler speak this is known as register pressure).
Obviously, -fschedule-insns2 doesn't suffer from this problem, since it only
schedules things after register allocation has been done (and thus on a machine
that has plenty of registers has little effect, other than to move spills
around).

--
Michael Meissner, Cygnus Solutions (Massachusetts office)
4th floor, 955 Massachusetts Avenue, Cambridge, MA 02139, USA
meissner@cygnus.com,	617-354-5416 (office),	617-354-7161 (fax)