std::pow implementation

[Alexandre Oliva]

On Aug  4, 2003, Bernd Schmidt <bernds@redhat.com> wrote:

> We've had -finline-functions (aka -O3) for years; it does what you
> suggest: let the compiler choose which functions to inline.  If we
> assume that this option does a reasonable job, it can be used if you
> want to write portable code and don't want to bother with performance
> measurements and suchlike.

I'd promised I'd step away from the debate, but my argument is being
misunderstood, so I'll just clarify.  I'm not arguing for the compiler
to disregard inline entirely, in that, if you don't mark a function as
candidate for inlining, the compiler won't even consider the
possibility of inlining.  However, if you do, it will evaluate whether
it appears to make sense to inline it in order to improve performance,
or whether the inline marker was there just to make the body of the
function visible for the translation unit, in case inlining was found
to be profitable.  Unfortunately, the only way to make the body
visible without violating the ODR is by marking the function as
inline, either with the inline keyword or by defining it inside the
class body.

> I propose that it have the effect expected by most people who aren't
> compiler hackers: let the function be inlined, if possible within
> reasonable limits (*).

We agree here.  The trick is to define what reasonable limits are.
Not everybody agrees that it's reasonable to get compile time or
generated code size to explode even if the program would still work.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer