Re: std::pow implementation

[Richard Earnshaw <rearnsha at arm dot com>]

> The analogy between the keywords "inline" and "register" is often made,
> but I think that it is inappropriate.  The reason is that we can do very
> good register allocation based only on local information, where the same
> is not true of many inlining decisions, which involve a more complicated
> set of tradeoffs (other than for very small functions; for such cases the
> compiler can reliably determine that an inlined call will be better by
> every measure than a non-inlined call).  When the goal is optimization
> for speed, detailed information about the cache and the execution profile
> will be needed in many cases for an accurate decision.

It's true that the similarities are weak, but there are similarites.  The 
most significant difference, as I see it, is that "inline" does introduce 
more information for the compiler to make use of (it provides the 
definition as well as the interface).

> In any case, at this stage in the state of the art of compiler
> development, we are not even close to the day where it's a good idea
> to just ignore the inline keyword.

I don't believe that we can ever entirely ignore "inline" in the way we 
ignore "register" because it does introduce (especially in C90) subtle 
changes of meaning for the code.  So the issue isn't really a matter of 
ignoring as much as "deciding" that in the current context calling an 
out-of-line copy is the more optimal solution.

This entire debate is really about how, and when, that decision gets made 
and what the heuristics for deciding it need to be.  The argument is so 
hot because there are occasions when trivial inline functions are not 
being inlined, but cranking up the metrics is leading to pathological 
behaviour.  Currently, GCC's heuristics are fairly dumb (a static count of 
the number of un-optimized tree nodes that are introduced).  A much better 
choice could probably be achieved if we did some optimization on the 
inline candidate before we made a decision the more optimizations the more 
likely we are to get a good choice (for example -- duplicate the tree, 
feed in the arguments from the current call site, run the tree-level 
optimizations and look at the size of the result.  If we've fed in 
constant arguments then the size of the result may be a tiny fraction of 
the original tree).

Maybe we should just have an option "-fdumb-inlining" and give the user 
the final choice (to quote an advert here in the UK "it does exactly what 
it says on the tin").  Eventually, we could probably make smart inlining 
so much better that nobody would need the "dumb" option.

R.