This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: On inlining in C++
- From: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- To: Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>
- Cc: Matthias Benkmann <matthias at winterdrache dot de>, <gcc at gcc dot gnu dot org>
- Date: 05 Aug 2003 15:21:36 +0200
- Subject: Re: On inlining in C++
- Organization: Integrable Solutions
- References: <Pine.LNX.4.44.0308051511020.14031-100000@bellatrix.tat.physik.uni-tuebingen.de>
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.
-- Gaby