Re: -fobey-inline (was Re: gcc and inlining)

[Richard Earnshaw <rearnsha at arm dot com>]

> On Sun, Mar 16, 2003 at 03:41:17PM -0300, Alexandre Oliva wrote:
> > On Mar 15, 2003, Bernd Schmidt <bernds at redhat dot com> wrote:
> > 
> > > And why not?  If I add the "inline" keyword, I do it for a good reason (I
> > > want the function inlined).
> > 
> > What if you don't add the `inline' keyword, but define a member
> > function inside the class body in C++?  Per the C++ Standard, such a
> > member function is implicitly `inline'.  Must this inline marker get
> > the same weight as a function defined outside the class body, with the
> > inline keyword explicitly given?
> 
> I would be willing to accept as a compromise that such implicit inline
> requests are somehow "weaker" than explicit use of the inline keyword.
> But it's frustrating to have to write nonstandard C++ (sorry, use of
> GNU directives is nonstandard) to get the compiler to behave as requested
> when the word "inline" is explicitly typed.
> 

Sitting back and thinking about this whole discussion I realise that there 
is a major distinction between -finline-functions and the inline keyword.  
The distinction lies in what may be assumed to be safe when inlining.

The C99 draft rationale cites an example of code that can behave 
differently when inlined from when it is not (though mainly in the case 
where the code is compiled into separate compilation units).  If we are 
considering inlining a call purely because of -finline-functions, then GCC 
had better be certain that doing so will not change the meaning of the 
program.  However, the presence of the inline keyword does indicate to the 
compiler that certain potentially ambiguous meanings can be ignored -- the 
programmer is effectively asserting that the ambiguities don't matter.

It seems that we are all getting very hung up over the issues that 
optimization is only about speed of the executable, that inlining should 
only be done after real measurements have been taken and that an 
application will only ever be written to run on one architecture.  While 
all of these considerations are true for some applications they can all 
clearly be false for others; and in probably the majority of cases at 
least one will not be true.  GCC is a compiler that targets many people 
who use it in many ways and we must take account of all users in any 
decision we reach or we will end up alienating everybody eventually.

Fact: some users want their application to be optimized for space.  In 
these circumstances we should probably only inline if code size will be 
reduced -- an example would be a single use of a static function, or when 
inlining will produce less code than the overhead of setting up a call 
(initializing arguments etc).

Fact: some users want their code to run on many platforms.  What then 
constitutes a good function to inline will depend on the platform (does it 
have only four registers, sixteen, or sixty-four?).  They don't want to do 
full measurements on every one, and even if they did they'd probably end 
up with conflicting answers.  They want the compiler to use its judgement 
as to when it is worthwhile to inline and when it is not.

I think what I'm trying to say is that we all accept that GCC's current 
inlining heuristics are broken and that it far too often fails to inline 
code that would be a good candidate for inlining.  But going to the other 
extreme would be equally wrong for another class of user.  We need to find 
the acceptable middle ground, which can only be done by making the 
compiler smarter, not by using a sledge-hammer.

Finally, I would also note that a compiler should also be free to 
un-inline parts of a function (factor them out into subroutine calls) if 
doing so allows it to satisfy the requested compilation goals.  The source 
code is simply a semantic expression of the problem.  There is no absolute 
requirement that the compiled code match its structure in terms of the 
blocks of assembly code that it generates, only that it match its meaning.

R.