This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: std::pow implementation


On Wed, 30 Jul 2003, Richard Guenther wrote:
> On 30 Jul 2003, Gabriel Dos Reis wrote:
> > Richard Earnshaw <> writes:
> > | > Richard Earnshaw <> 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

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.

Richard B. Kreckel

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]