This is the mail archive of the gcc@gcc.gnu.org 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 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.

> | > | With Gaby's suggested interpretation, the compiler has *no* choice; it
> | > | must obey the inlining constraint because the programmer always knows
> | > | better...  Even when prepared to admit that he doesn't.
> | >
> | > That assertion is wrong.
> |
> | Which bit of it?  It's what I understand you to be suggesting.
>
> As I've repeatedly said, there are pathological cases where the
> compiler simply cannot inline.  Secondly, I'm saying that the
> compiler does not always know better than the programmer.  And in fact,
> the programmer most of the time declares "inline" on purpose.
>
> Transmuting the meaning of "inline" is creating more fear, uncertainty
> and doubt than we needed.

So what are the semantics of the "inline" keyword you propose? What I read
into your statements is something like "the compiler should inline a
function if I want it to be inline, and he should read my mind for
deciding this."

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).

Richard.


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