std::pow implementation

[Richard B. Kreckel]

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/>