Re: GCC 3.3 release criteria

[Richard Earnshaw <rearnsha at arm dot com>]

> On Tue, 25 Feb 2003, Richard Earnshaw wrote:
> 
> > The cases in C where I've seen people get most upset about the compiler 
> > not using inline are when the program has subtly different semantics once 
> > inlining has occurred (for example, taking the address of a label and then 
> > using that as a key in a debug message).  But these are precisely the 
> > types of cases where we probably don't want inlining: relying on such 
> > optimization to get correct behaviour is a dangerous mistake.
> 
> I was rather upset when I discovered the inline keyword was no longer
> honoured by gcc.  One of my applications uses inlining to reduce code
> duplication without hurting performance.  I have a few time-critical
> functions of the form
> 
> inline void f (int arg1, int arg2, int arg3)
> {
>    ... several loops deep..
>    {
>        if (arg1 == 1)
> 	  foo;
>        else
> 	  bar;
>    }
> }
> 
> I know the range of the values the arguments can have, and I use inlining
> to move the tests out of the loops without having to duplicate all the
> loop bodies by hand.
> 
> I have 
>   void f_2_3_1 () { f (2, 3, 1); }
> etc. (these will expand into optimized versions of f) as well as a frontend
> function that takes arg1, arg2 and arg3 and decides which of the f_x_y_z
> to call.
> 
> The effect is maybe slightly similar to C++ templates.  Needless to say,
> it completely fell apart with gcc-3.0 which decided it was smarter than
> the programmer.
> 
> I would like something like -fobey-inline to be the default.

What's really needed is to make gcc's inlining heuristics smarter, not to 
provide a crowbar which rides roughshod over everything.

For example, gcc's inlining metrics should probably take into account the 
number of constants that are passed as arguments to a function 
(particularly if it could be made to see that such arguments are used in a 
manner that would fold conditional expressions).

Also remember that what's good as an inline function on one architecture 
might be terrible on another (for example, because it leads to excessive 
spilling).

R.