Re: On inlining in C++

[Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>]

On 5 Aug 2003, Gabriel Dos Reis wrote:

> Richard Guenther <rguenth@tat.physik.uni-tuebingen.de> writes:
>
> | On 5 Aug 2003, Gabriel Dos Reis wrote:
> |
> | > Richard Guenther <rguenth@tat.physik.uni-tuebingen.de> writes:
> | >
> | > | The point is, all these "people will optimize" suggestions go against
> | > | portability to different compilers.
> | >
> | > It is going to be non portable only if compiler back ends decide they
> | > know better and don't trust the programmer preference.  Inline in C++
> | > precisely to cut down the non-portability.  Inline in C++ does not
> | > mean "hey back-end, optimize this as you want".
> |
> | The standard doesnt say something explicit about this. And current
> | practice of most compilers I know is to either ignore "inline" or give it
> | a boost in any heuristics they use. Most of them are weak in inlining
> | decisions (or fail to honour "inline"),
>
> Not just because some can fail to do their jobs means GCC also should fail
> as well. Others don't fail and GCC should be among those.  Give the
> obvious meaning and trust the programmer.
> If you actually do better than  obvious "inline" in most cases, then
> the programmer will choose.  But the fact is, you don't.  Until you
> do, give the programmer the obvious meaning so that she can
> consistently make her decisions.
>
> inline is already there, we don't need a revinvention.

This is the answer only to those cases where existing compiler technology
can decide already, namely for small functions falling out of abstraction
and protection stuff.

I have lots of code where inlining a method blows up compile and hits
executable size if "inline" is treated literally, but in one or two places
this inlining is absolutely necessary to allow loop optimizations to take
place. The C++ standard doesnt offer a solution to this problem other than
perhaps wrapping those methods into funny dont-inline methods like Thomas
Kunert proposed (but then, a smart compiler would inline noinline_f() as
it contains only one function call and such resulting code is always
smaller?).

Richard.

--
Richard Guenther <richard dot guenther at uni-tuebingen dot de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/