Re: avoiding 'static inline'

[Paul Eggert]

Thanks, Bruno, for reviewing the patches.  I installed the
noncontroversial ones and have the following further comments.

On 08/19/2012 01:14 PM, Bruno Haible wrote:

>   - Inlining is worth it when the function is small (ca. 3-5 instructions),
>     so that the inlined code is smaller or otherwise faster to execute
>     than an explicit function call (which also takes 3-5 instructions on
>     average).

Yes, and my experience is that GCC and other modern compilers do a
good job of this without 'inline'.  There are some exceptions, of
course.

A good rule of thumb is to use 'static inline' (as opposed to
plain 'static') when we know there's a significant performance
advantage on some platform of importance to the GNU project, and
no significant downsides on important platforms.

>   - I've seen speedups of 10% just by replacing 'static' with 'static inline'
>     on judiciously chosen functions in the past (with "gcc -O2" a couple
>     of years ago).

Yes, these are the exceptional cases, and I think we should keep
these uses of 'inline'.  I assume lib/streq.h is an example of
this, which is why I've left it alone.  (Though we may want to
change it to use extern inline at some point...)

> I object against
>   01/16
>   03/16
>   04/16
>   06/16
>   07/16
>   08/16
>   09/16
>   10/16
>   12/16
>   13/16
> because inlining is desirable for these small functions, regardless of
> compiler.

It's not *always* desirable.  Inlining can complicate debugging,
and can run afoul of compiler bugs.  With modern GCC and typical
-O2 optimization, there should be no significant performance
advantage to those uses of 'inline', so why take the risk?

> And I object against
>   02/16
> because for compilers that don't automatically remove unused 'static'
> functions this will add a lot of code bloat (multiple copies of the
> function).

02/16 affects only pre-C99 compilers.  Which of these are you
worried about?  If they're doing it with optimization disabled
then there's little to worry about.  If they're doing it with
default optimization, and if they're of importance to the GNU
project, I'd like to know more.

Perhaps we could do the 02/16 change on most platforms, but
suppress it for the older compilers where it significantly hurts
optimized performance.