RE: std::pow implementation

["Rob Taylor" <robt at flyingpig dot com>]

I've been following this thread, and i'm strating to get confused about
exactly who's arguing for what!!

as is read it, there seem to be 3 positions:

1) every function has to be maybe-inlinable for good optimisation, so we
should ignore the inline keyword

2)  every function has to be maybe-inlinable for good optimisation, but the
inline keyword gives good hinting and should be used.

3) every function has to be maybe-inlinable for good optimisation, but those
declared inline should have a non-contextual rule for inlining, as opposed
to a contextual analysis approach for those not declared inline. <not sure
of my analysis here>

Is this correct? and who's in which court? what have i missed out?

Thanks,

Rob Taylor



> -----Original Message-----
> From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@gcc.gnu.org]On Behalf Of
> Richard Guenther
> Sent: 31 July 2003 11:02
> To: Gabriel Dos Reis
> Cc: Martin Reinecke; gcc@gcc.gnu.org
> Subject: Re: std::pow implementation
>
>
>  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/
>