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

[Bernd Schmidt <bernds at redhat dot com>]

On Sat, 15 Mar 2003, Robert Dewar wrote:

> What the inline keyword means is
> 
> "Speed is really important when calling this small function, you can if you
> like use more space if it helps execution speed.
> 
>  I am guessing that a good idea would be to
> inline the code at the point of each call and that this would help execution
> speed. I base this guess on a naive view that the function likely generates
> only a few instructions, so that the overhead of the instructions for
> calling and returning will be significant, and this kind of inlining can
> get rid of this overhead"

Paraphrased, this is equivalent to "I really don't know what's going on here,
please make a decision for me".  We have support for this, it's called
"-finline-functions".  For trivial situations like the one you describe, the
compiler can usually make a good guess.

However, "inline" can mean different things as well.  For example,
  "I know that this function is always called with constant arguments and
  that'll allow you to constant fold all the if statements in the innermost
  loop if you inline it as I told you to.  Please ignore the fact that it's
  large, all the call sites are otherwise empty functions that aren't
  themselves inlined, and only one of them is ever going to be used at
  runtime, so please ignore icache pressure as well since there isn't any."

Or, as much as you may dislike it,
  "This code will only ever run on a VAX.  With typical input, I've measured
  that it runs twice as fast if the function is inlined.  If it ever runs on
  anything other than a VAX we'll redo the measurements."

> Now the compiler should react to this by actually doing the inlining if
> indeed doing so can reasonbly be expected to improve execution time.

IMO this problem is AI-complete.


Bernd