Inlining

Server NGINX
1

Looking through the codebase, I see a lot of very short helper like
functions that are defined in .c files with prototypes in .h files. This
means that the compiler cannot inline them outside of that .c file. Am I
wrong? How is that not a performance hit?

Ata.

Posted at Nginx Forum:

2

I suppose they will be inlined at -O2 level:

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

On Friday, February 14, 2014 04:59:26 PM atarob wrote:

nginx mailing list
[email protected]
nginx Info Page
–
Best regards,
Styopa S…

3

On Friday, February 14, 2014 04:59:26 PM atarob wrote:

Looking through the codebase, I see a lot of very short helper like
functions that are defined in .c files with prototypes in .h files.
This
means that the compiler cannot inline them outside of that .c file.
Am I
wrong? How is that not a performance hit?

I suppose they will be inlined at -O2 level:
gcc(1): GNU project C/C++ compiler - Linux man page

Think about it. -O2 is a compiler flag. Optimization happens at compile
time. NOT at link time. If the function is defined in another .c file,
how
can the compiler, which compiles on .c file at a time, possibly have
access
to the definition, let alone inline it. That’s why we put inline
function
that are supposed to be called by other .c files in a .h file. Am I
wrong?

Ata.

Posted at Nginx Forum:

4

Hello!

On Fri, Feb 14, 2014 at 04:59:26PM -0500, atarob wrote:

Looking through the codebase, I see a lot of very short helper like
functions that are defined in .c files with prototypes in .h files. This
means that the compiler cannot inline them outside of that .c file. Am I
wrong? How is that not a performance hit?

In no particular order:

  • As already pointed out, smart enough compilers can inline
    whatever they want.

  • Adding all functions to .h files results in unmanagable code, so
    there should be a bar somewhere.

  • In many cases inlining may actually be a bad idea even from
    performance point of view, see, e.g., [1].

  • If inlining is considired to be beneficial, in most
    cases nginx uses macros rather than inline functions, see, e.g.,
    src/core/ngx_queue.h.

If you think there are functions which needs be be made
inlineable - feel free to suggest.

[1]

–
Maxim D.
http://nginx.org/

5

Pankaj Mehta Wrote:

These should be covered during the link time optimisations.

Look here for gcc: LinkTimeOptimization - GCC Wiki

I was very much unaware of this. The linker actually compiles… Wow.

Thanks.

Posted at Nginx Forum:

6

On Tue, Feb 18, 2014 at 2:51 PM, atarob [email protected] wrote:

Pankaj Mehta Wrote:

These should be covered during the link time optimisations.

Look here for gcc: LinkTimeOptimization - GCC Wiki

I was very much unaware of this. The linker actually compiles… Wow.

LTO also allows the linker to silently drop code with undefined
behavior. The compiler and linker are free to do what they want with
UB, including making demons fly out your nose [0].

So if the code includes, for example, signed integer overflow, then it
may result in incorrect results. The baffling thing will be when the
test suite passed earlier becuase the UB was not detected under the
test suite.

Jeff

[0]
https://groups.google.com/forum/?hl=en#!msg/comp.std.c/ycpVKxTZkgw/S2hHdTbv4d8J

7

These should be covered during the link time optimisations.

Look here for gcc: LinkTimeOptimization - GCC Wiki

And here for Visual Studio :

Cheers
Pankaj