Re: [MiNT] Re: GCC

[Johan Klockars <rand@cd.chalmers.se>]

> > That's actually better than I get with egcs 1.1.1 (the code I posted was
...
> 2.91.60.s = egcs 1.1.1 release

The 1.1.1 I have is from 980707 and it was supposed to be the real one
according to the place I got it from.

Is yours one of the 'work in progress' versions, or does it perhaps use
some other m68k-definition files?

> > You know that this will auto-inline functions, I hope?
> 
> Yes, and?

Well, lots of people seem to just add -O9 and assume that it will make
their code nice and fast.
Function inlining does not necessarily make things faster (you can run out
of cache space) and it can cause the generated code to be come a lot bigger.

> > >  * -fno-defer-pop
> > 
> > Uhm, that will actually slow the code down since you'll get extra adds
> > to register a7. Might make it somewhat easier to debug by hand, though.
> 
> Draco mean it produce faster and better code.

     -fno-defer-pop
          Always pop the arguments to each function call as  soon
          as  that function returns.  For machines which must pop
          arguments after a function call, the compiler  normally
          lets  arguments  accumulate  on  the  stack for several
          function calls and pops them all at once.

If you had a machine with a small cache used in copyback mode, this could
possibly cause a speedup (since the same stack space is reused in the
stack, reducing the risk of a write to memory), but otherwise you'll
only get extra additions to the stack pointer for no reason.
Naturally, the performance benefit of defering the pops is very marginal,
but it should be a win unless there's something wrong with the compiler.

> > >  * -fexpensive-optimizations
> > >  * -fstrength-reduce
> > 
> > Both of those are included by default even with -O2 according to all
> > gcc documentation I've ever seen.
> 
> Hmm, the documentation is a little bit inexact I mean.

Well, this text is perhaps somewhat inexact (but see below):

     -O2  Optimize even more.  Nearly all supported optimizations
          that  do  not  involve  a space-speed tradeoff are per-
          formed.  Loop unrolling and function inlining  are  not
          done,  for example.  As compared to -O, this option in-
          creases both compilation time and  the  performance  of
          the generated code.

     -O3  Optimize yet more. This turns on everything  -O2  does,
          along with also turning on -finline-functions.


You can also find this in the man pages, which is very explicit:

     The following options control specific  optimizations.   The
     `-O2'  option  turns  on  all  of these optimizations except
     `-funroll-loops' and `-funroll-all-loops'.
...
     You can use the following  flags  in  the  rare  cases  when
     "fine-tuning" of optimizations to be performed is desired.
...
     -fstrength-reduce
          Perform the optimizations of  loop  strength  reduction
          and elimination of iteration variables.

     -fexpensive-optimizations
          Perform a number of minor optimizations that are  rela-
          tively expensive.
...

There are a lot of other optimizations mentioned, but it's clear
that the these two are on with -O2.


A couple of other gcc options that might be useful:

     -fforce-mem
          Force memory operands to be copied into  registers  be-
          fore doing arithmetic on them.  This may produce better
          code by making all memory references  potential  common
          subexpressions.   When  they  are not common subexpres-
          sions, instruction  combination  should  eliminate  the
          separate  register-load.   I  am  interested in hearing
          about the difference this makes.

     -fforce-addr
          Force memory address constants to be copied into regis-
          ters before doing arithmetic on them.  This may produce
          better code just as `-fforce-mem' may.  I am interested
          in hearing about the difference this makes.

GNU Tools            Last change: 1998/07/08                   32

-- 
  Chalmers University   | Why are these |  e-mail:   rand@cd.chalmers.se
     of Technology      |  .signatures  |            johan@rand.thn.htu.se
                        | so hard to do |  WWW/ftp:  rand.thn.htu.se
   Gothenburg, Sweden   |     well?     |            (MGIFv5, QLem, BAD MOOD)