[m-rev.] proposed addition to coding standards

[Peter Moulder]

On Sun, Nov 16, 2003 at 12:40:27AM +1100, Fergus Henderson wrote:
> On 15-Nov-2003, Peter Moulder <Peter.Moulder at infotech.monash.edu.au> wrote:
> > 
> > Note that following this proposal for C code means that gcc (3.3.2, -O2) 
> > will do no inlining of functions where the caller and callee are defined
> > in the same source file, because gcc-3.3 -O2 won't inline functions whose
> > definition appears after the call in the translation unit.
> 
> In that case, we should compile our C files (runtime/*, trace/*) with gcc -O3.

I gather that -O3 sometimes produces larger .o files than -O2 (e.g. due to
inlining some functions that weren't requested to be inlined), though I
don't have any data.

Relevant information from gcc manual:

 `-O3'
     Optimize yet more [than -O2].  `-O3' turns on all optimizations
     specified by `-O2' and also turns on the `-finline-functions' and
     `-frename-registers' options.

 `-finline-functions'
     Integrate all simple functions into their callers.  The compiler
     heuristically decides which functions are simple enough to be worth
     integrating in this way.

     If all calls to a given function are integrated, and the function
     is declared `static', then the function is normally not output as
     assembler code in its own right.

 `-frename-registers'
     Attempt to avoid false dependencies in scheduled code by making use
     of registers left over after register allocation.  This
     optimization will most benefit processors with lots of registers.
     It can, however, make debugging impossible, since variables will
     no longer stay in a "home register".

 `--param max-inline-insns-auto=N'
     When you use `-finline-functions' (included in `-O3'), a lot of
     functions that would otherwise not be considered for inlining by
     the compiler will be investigated.  To those functions, a different
     (more restrictive) limit compared to functions declared inline can
     be applied.  The default value is 300.

(There are many other such parameters controlling inlining decisions;
see `-finline-limits' and its references, at
<http://gcc.gnu.org/onlinedocs/gcc-3.3.2/gcc/Optimize-Options.html>.)

We may choose to disable -frename-registers (e.g. specify `-O2
-finline-functions' instead of `-O3') if we wish to allow use of gdb for
{trace,runtime}/*.c.

Independent of that possibility, we wish to add `-finline-limits=N' or
`--param max-inline-insns-auto=N', or perhaps one of the other inlining
limiters, if we wish to reduce bloat caused by needless inlining.  I'd
guess that trace/* in particular should have tight inlining limits
(optimizing for space rather than number of instructions executed).

Of course there's also an advantage in keeping the options short,
say `-O2' or `-O3'.  Less distraction in makefiles & output.

It may be appropriate to file a bug with gcc: the descriptions of -O2
and -Os suggest that such trivial functions as int bar() { return 42; }
should be inlined by -O2 and by -Os, probably even in absence of an
explicit `inline' request.  (`{ return somevar; }' is a more real-world
example.)  Without being familiar with gcc, I'd have thought that there
exist values for the existing inline-limiting parameters that are large
enough to cover those two examples and (more importantly) small enough
to always produce smaller code than without inlining.  Can anyone
comment on this hypothesis offhand?  I haven't checked whether or not
such a bug report has already been filed, btw.

pjm.
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------