Re: std::pow implementation

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

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

|  Martin Reinecke <martin@mpa-garching.mpg.de> writes:
| 
|  | Gabriel Dos Reis wrote:
|  |
|  | > It is tempting to make the analogy with "register", but you have to
|  | > acknowledge the fact that inlining strategy is not at the same level
|  | > of sophistication as register allocation.  Therefore, any answer you
|  | > get for the question above is irrelevant to whether you should decide
|  | > whether your programmed inliner always knows better than the
|  | > programmer.   Until then, please listen to the programmer.  Don't
|  | > transmute "inline".
|  |
|  | Yes, you should listen to the programmer. But unless the programmer
|  | has a chance to express his intent _exactly_, there is no way to find
|  | out what he really meant. And he cannot do so in the discussed situation.
| 
|   How to be sure there would not be another quibble about whether he
|   really wanted to express exactly his intent?  something like
| 
|      [P] inline
|      [C] do you inline mean inline?
|      [P] Yes
|      [C] Are you sure you really mean inline?
|      [P] Yes
|      [C] Did you mean the last answer?
|      [P] ...
| 
| Ah, come on, stop whining and making this list look like a Kindergarten.

because it is :-)

|   That way lies infinite recursion with no way of getting started,
|   i.e. no productive work.  We don't need complication to get decent
|   results.  KCC didn't need a hierarchy of intent of inline before
|   producing much better code.  When we will reach the level where the
|   compiler trusts the programmer, we could start worrying about what is
|   next.  Like they say here, Paris is built in one day.
|   First, start trusting the programmer; when you're good at that job, you
|   would be able to handle subtile  distinctions.
| 
| Martin is right that there is a lack of being able to express what one
| means.

I'm not saying he is wrong.  I'm saying, let's tackle that tower latter
when we know how to build a two floor house, because getting two-floor
house good now is a more urgent issue than building a babel tomorrow.

| And which this lack you cannot be sure if the programmer with
| "inline" meant inline or maybe inline. 

And you won't be sure either that the three stage is sufficient for the
programmer.  We're not at the stage of designing a language from scratch.

| You cannot even be sure if he meant
| do not inline if he omitted inline. It doesnt help that _you_ mean inline
| if you write it.
| 
| So face it - gcc _has_ to map both "inline" and not "inline" to
| maybe-inline. There are (non portable) ways to specify do not inline
| (attribute noinline) and do always inline (attribute always_inline).
| The way out of this discussion is to make gcc's heuristics better, not to
| force it into any static notion about "inline" or not "inline".

Please do be careful about the fact that I'm not proposing that g++
should not inline a function not marked inline.

-- Gaby