Re: [EGCS] Optimizations

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)

Re: Optimizations

[Marc Lehmann]

On Sun, Dec 14, 1997 at 05:30:48PM -0500, meissner@cygnus.com 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)
> 
> The problem is that -fschedule-insns, -funroll-{,all-}loops, and
> -fstrength-reduce all tend to work by creating more registers to hold

The really intersting point is that -fschedule-insns ins generally a loss
on x86, while -funroll-all-loops is generally a win! (even more
so that -funroll-loops)

I guess loop unrolling should be more clever, i.e. while it should
unroll loops without constant number ofm iterations, it should'nt
unroll all of them.

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

Re: Optimizations

[Dave Love]

>>>>> "Marc" == Marc Lehmann <pcg@goof.com> writes:

 Marc> on x86, while -funroll-all-loops is generally a win! (even more
 Marc> so that -funroll-loops)

Could someone explain exactly what is the difference between the sort
of loops unrolled by -funroll-all-loops and -funroll-loops?  The doc
sentence isn't clear to me and ISTR that grovelling unroll.c wasn't
immediately enlightening.  Is it something like for(;;) versus
for(i=1;i<=n;i++)?

BTW, in case the original question fortran-related, at least for
fortran with the default (non-)aliasing model, -fforce-addr can be a
win on x86 as Toon has pointed out.  BTW2, the suggestions for [56]86
options with -malign-...=2 are propagated -- bother -- in the g77
manual, AFAIR after the Linux GCC-HOWTO.

Re: Optimizations

[Marc Lehmann]

> fortran with the default (non-)aliasing model, -fforce-addr can be a
> win on x86 as Toon has pointed out.  BTW2, the suggestions for [56]86
> options with -malign-...=2 are propagated -- bother -- in the g77

could someone check this? I'm pretty sure that (on pentiums!),
4 byte alignment is worse than either zero or 16 byte alignment,
and there is no point in wasting space when zero alignment is at
least equally well.

I never saw benchmark data (except mine) that said 4 byte is better then
zero byte alignment (and intel itself recommends 0 on pentiums).

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

Re: Optimizations

[Stan Cox]

>I never saw benchmark data (except mine) that said 4 byte is better then
>zero byte alignment (and intel itself recommends 0 on pentiums).

gas and the svr4 assembler have pseudoops that say align to X bytes if it takes no
more than Y bytes to do so.  We used this in the DG/UX configuration
after doing quite a bit of benchmark analysis.
-- 

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: [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                        |
                                                          |