This is the mail archive of the
mailing list for the GCC project.
Re: On inlining in C++
- From: Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>
- To: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- Cc: Matthias Benkmann <matthias at winterdrache dot de>, <gcc at gcc dot gnu dot org>
- Date: Tue, 5 Aug 2003 15:28:59 +0200 (CEST)
- Subject: Re: On inlining in C++
On 5 Aug 2003, Gabriel Dos Reis wrote:
> Richard Guenther <firstname.lastname@example.org> writes:
> | On 5 Aug 2003, Gabriel Dos Reis wrote:
> | > Richard Guenther <email@example.com> 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
Richard Guenther <richard dot guenther at uni-tuebingen dot de>