issues with inlining

[Carlo Wood]

Imho there are serious problems with inlining and gcc 3.x.

As most of you know, I am not a compiler hacker, but
extensively using the compiler for every day development
of C++ libraries and recently I've laid my eyes on optimization
issues (needing fast code and all).

The inlining problems exist of functions not being inlined
that should have been inlined, and others getting inlined
while they would better not have been inlined.

The following problems have been spotted:

1) -Winline doesn't give me a warning when a function is
   not inlined, even while I am using the inline keyword
   for it.
2) g++ 3.2.1 seems to totally ignore the inline keyword
   and do as it pleases when being used with -O3.  
   Unfortunately, I know better than the compiler what
   should be inlined - so, ignoring the inline keyword
   and inlining other functions results in much slower
   code.
3) Apparently gcc is still inlining "top down", meaning
   that when a() calls b() which calls c() which calls d(),
   then b() is inlined into a(), c() is inlined into
   d() and when then the function becomes too big, it
   stops.  THIS IS HORRIBLE!!!  This *definitely* needs
   to be changed into that d() is inlined into c(),
   and if the function isn't getting too big, then c()
   into b() etc.
4) The instruction limit that can be set with -finline-limit
   seems to count instructions before optimization...
   This means that I need to give a limit of 8000 instructions
   before everything is inlined - although after optimization
   hardly anything is left (maybe 50 to 100 instructions, way
   below the default 600 threshold).
   By the time I get my inner functions inlined this way,
   EVERYTHING is inlined (I get one big function call of
   120,000 instructions :/ (after compiling 60 minutes)).

The reason for this functionality failure is imho related
to templates: With C++ templates it happens that more and
more code is available at the same time, unlike for C code.
Code with lots and lots of templates (like my code) exists
often for 95% of header files.  That makes it increasingly
important for the compiler to start inlining "bottom up",
and to honour 'inline' keywords by giving them a high priority.

-- 
Carlo Wood <carlo@alinoe.com>