Re: inline for bug #41178

[Rik]

On 12/12/2015 09:01 AM, address@hidden wrote:

Subject:

Re: Fix for bug #41178

From:

Mike Miller <address@hidden>

Date:

12/11/2015 01:57 PM

To:

Octave-Maintainers <address@hidden>

List-Post:

<mailto:address@hidden>

Precedence:

list

MIME-Version:

1.0

References:

<address@hidden>

In-Reply-To:

<address@hidden>

Message-ID:

<address@hidden>

Content-Type:

text/plain; charset=utf-8

Message:

1

On Fri, Dec 11, 2015 at 12:11:26 -0800, Rik wrote:

> The fix for bug #41178 was simply to move a function from a header file to
> a .cc file.  Given that the function is just one line, shouldn't it be
> declared as inline now that it is no longer in the header file?

Can you demonstrate that that will have any effect? My understanding is
that "inline" is a hint to the compiler, and only when the function body
is available via the header file. I think adding the word "inline" would
have no effect at all.

Mike,

It's complicated because there is a mix of mandated standard and implementation specific detail.  First, the C++ standard requires that member functions *with* their function bodies within a class definition must be implicitly marked as inline.  By moving the function body from the header file to the .cc file the implicit inline is dropped.

But, "inline" is only a hint to the compiler.  So does marking a function inline or not really matter?  For most of us on Linux the compiler of choice is gcc so that is the implementation to consult (https://gcc.gnu.org/onlinedocs/gcc/Inline.html).  First, gcc does not do inlining if optimization is turned off as might happen when you want to do debugging.  Options for inlining from the man page are

 -finline-small-functions
           Integrate functions into their callers when their body is smaller than expected function call code
           (so overall size of program gets smaller).  The compiler heuristically decides which functions are
           simple enough to be worth integrating in this way.

           Enabled at level -O2.

  -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.

           Enabled at level -O3.

So there is a small difference.  At level -O1 functions declared inline will, in fact, be made inline as long as they meet the other requirements for inlining of a function.  At level -O2, which most of us compile at, you would expect that a single line function like the one in question would be made inline thanks to -finline-small-functions.  I don't think it is practically necessary in this case on most Linux machines to add the "inline" keyword, but I also don't think it hurts.  Adding "inline" expresses the intent of the programmer, but might be ignored by the compiler.  Similarly, comments in the code express the intent of the programmer, and are definitely ignored by the compiler, but are still seen as useful.

In the nitty gritty of gcc there are also some params to control the inlining process.

          max-inline-insns-single
               Several parameters control the tree inliner used in gcc.  This number sets the maximum number of
               instructions (counted in GCC's internal representation) in a single function that the tree
               inliner will consider for inlining.  This only affects functions declared inline and methods
               implemented in a class declaration (C++).  The default value is 400.

           max-inline-insns-auto
               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 40.

One can see that using "inline" more generally than in this case *might* actually have an effect and therefore *might* be a useful hint.

This took way more time to evaluate than could ever be rationally justified, but at least I got to learn some stuff along the way.  I added the keyword "inline" on the development branch in this cset (http://hg.savannah.gnu.org/hgweb/octave/rev/ece3bb10c712).

--Rik