This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: std::pow implementation
- From: "Richard B. Kreckel" <kreckel at ginac dot de>
- To: <gcc at gcc dot gnu dot org>
- Cc: Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>, Gabriel Dos Reis <gdr at integrable-solutions dot net>, <Richard dot Earnshaw at arm dot com>, Karel Gardas <kgardas at objectsecurity dot com>, Alexandre Oliva <aoliva at redhat dot com>
- Date: Wed, 30 Jul 2003 23:49:50 +0200 (CEST)
- Subject: Re: std::pow implementation
- Reply-to: <Richard dot Kreckel at ginac dot de>
Hi,
On Wed, 30 Jul 2003, Richard Guenther wrote:
> On 30 Jul 2003, Gabriel Dos Reis wrote:
> > Richard Earnshaw <rearnsha@arm.com> writes:
> > | > Richard Earnshaw <rearnsha@arm.com> writes:
> > | > [...]
> > | > | Now, assume that the amount of code in the a!=1 case is reduced. At what
> > | > | point does it become beneficial to always inline? Can the programmer
> > | > | tell?
> > | >
> > | > He can profile.
> > |
> > | Profiling doesn't help if the answer comes back as "sometimes" (function
> > | foo's use of bar is best inlined, function wibble's use of bar is best not
> > | inlined).
> >
> > The cases where it most does not help is when the compiler decides it
> > knows better and goes on using his own programmed logic.
>
> Oh - I thought you meant profile directed inlining decisions by the
> compiler, not by the user. The latter is not useful.
Sometimes, the latter *is* useful. For a project where speed was quite
essential I have once gone through the whole cycle (trial inline) ->
(compile) -> (benchmark/profile/read the disassembled output) several
dozen times till I found out some good inlining patterns. Without profile
directed inlining at a global level there isn't any alternative in extreme
cases.
Transmuting the meaning of "inline" *is* counterproductive. The compiler
should trust the programmer.
[...]
> The only sane possible semantics I see are:
>
> 1. inline declared functions are inlined always if technically possible
> 2. the inline keyword has no effect
> 3. inline is handled in an implementation defined manner (as stated in the
> standard), maybe by adjusting the set of functions considered for inlining,
> as gcc does.
>
> I argue we cannot go away from #3 without portability problems (to other
> compilers and architectures).
I cannot agree. Sticking to the original meaning of "inline" (a
combination of #1 and #3, as Gaby proposed) will definitely reduce
portability problems, to other compilers at least. The fact that many
compilers come up with their own semantics is quite sad.
Regards
-richy.
--
Richard B. Kreckel
<Richard.Kreckel@GiNaC.DE>
<http://www.ginac.de/~kreckel/>