Re: std::pow implementation

[Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>]

 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.

  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. And which this lack you cannot be sure if the programmer with
"inline" meant inline or maybe inline. 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".

Richard.

--
Richard Guenther <richard dot guenther at uni-tuebingen dot de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/