std::pow implementation

[Gabriel Dos Reis]

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.

[...]

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

-- Gaby