Re: std::pow implementation

[dewar at gnat dot com (Robert Dewar)]

> (*) Reasons why I'd accept inline not being honoured:
>   - the function would become too big for the machine (or any other reason
>     why the code wouldn't work)
>   - recursive functions
>   - alloca or some other feature that causes stack size explosions
>     is used.  We should warn - this is a case for always_inline
>     (Likewise for any dodgy GNU extensions I'm forgetting right now)
>   - the compiler would explode due to lack of memory - we should make an
>     effort this doesn't become a frequent reason
>   - the programmer used -Os (and we can prove the code would get bigger)


I would add

- doing the inlining as requested increases both the space and execution time
of the program, the former very substantially.

Of course, the question is

1. Does this happen often in practice (certainly as I Have noted before we
often see that -O3 slows things down compared to -O2: speed = space in the
land of icaches).

2. Can the compiler really usefully tell this is the case, or does it make
so many mistakes trying to be helpful in this way that it actually hurts.

With regard to the "collapsing code" issue, clearly the best strategy is
to do parameter substitution and collapse the code *before* deciding whether
to inline it. Of course this is not so easy to do.