std::pow implementation

[Gabriel Dos Reis]

Richard Guenther <rguenth@tat.physik.uni-tuebingen.de> writes:

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

I'm not excluding profile directed inlining. But we don't have
architecture in place for that yet.

[...]

| 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'm arguing for #1 and #3 combined.  Meaning, inline simple functions
at low optimization level, try hard at higher level + compiler
parameter adjustement.

-- Gaby