This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: std::pow implementation
- From: Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>
- To: Steven Bosscher <s dot bosscher at student dot tudelft dot nl>
- Cc: Scott Robert Ladd <coyote at coyotegulch dot com>, Alexandre Oliva <aoliva at redhat dot com>, Gabriel Dos Reis <gdr at integrable-solutions dot net>, <gcc at gcc dot gnu dot org>
- Date: Wed, 30 Jul 2003 17:41:25 +0200 (CEST)
- Subject: Re: std::pow implementation
On 30 Jul 2003, Steven Bosscher wrote:
> Op wo 30-07-2003, om 17:28 schreef Scott Robert Ladd:
> > Alexandre Oliva wrote:
> > > Therefore, inline the way you describe it, is useful only for
> > > functions that are *always* profitable to inline. Any function that
> > > might or might not be profitable to inline should not be declared
> > > inline, and the compiler would never inline it. This sounds silly to
> > > me. Why not let the user tell the compiler `hey, look, this
> > > function is probably worth trying to inline', but letting the
> > > compiler decide whether it's actually profitable or not, depending
> > > not only on the context, but also on machine-dependent features?
> >
> > IMNSHO, the keyword "inline" means precisely what it says: to inline the
> > code for a given function, if possible.
>
> Richard Guenther's experience with this meaning for "inline" are not
> that positive: http://gcc.gnu.org/ml/gcc/2003-07/msg02140.html.
> And then he's the guy who always wants more inlining :-p
Well - I always want more performance ;) And this can be achieved if
inlining the right functions at the right places... which translates also
to "the inline keyword as suggested by Gabriel doesnt fit my needs". The
suggested extra #pragmas or function attribute do, but of course a
"smarter" compiler doesnt hurt as well (though I doubt it will ever come
near the leafify attribute, at least not without profiling feedback).
Richard.