Re: On inlining in C++

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

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

but we're having this debate in part because that compiler decision
does match documented behaviour.

| I have lots of code where inlining a method blows up compile and hits
| executable size if "inline" is treated literally,

It seems like you want the compiler to decide for you, GCC seems to
have a flag for that.

|  but in one or two places
| this inlining is absolutely necessary to allow loop optimizations to take
| place. 

Then let's have the compiler honour inline, be consistent, most of of
the time predictable. It will cover those cases, and for the case
you're not sure, don't use "inline", let's the compiler decide for you.

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

I'll repeat what I said earlier:  If you think that C++ should offer
such thing, then you should submit a proposal or convince someone on
the committee to do so.

-- Gaby