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: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 29 Jul 2003 14:10:07 +0200 (CEST)
- Subject: Re: std::pow implementation
On 29 Jul 2003, Gabriel Dos Reis wrote:
> Richard Guenther <rguenth@tat.physik.uni-tuebingen.de> writes:
>
> | for my scientific app. If this ends up the same way as the
> | __attribute__((leafify)) discussion, I'll stop complaining now and instead
> | just file a PR for the record.
>
> I bet your application will benefit much more from a better inlining
> support in the compiler than obfuscating the library.
> (Note that it need not be a sophisticated inliner). We get to that point
> because, at some point it was decided that the compiler knows better
> than the programmer.
Of course, and the recent changes in inlining heuristics and the
unit-at-a-time support for C++ in 3.4 got it a huge boost. But it still
gets nowhere near the code I manage to get by giving the leafify hint to
the compiler at exactly three locations. At some point the user _will_
know better - why do you think we have __attribute__((always_inline)) and
__attribute__((noinline))? Why do we have means to control the inlining
heuristics at all? Do you expect us to arrive to a point where all these
are unnecessary?
The std::pow stuff is now libstdc++/11706 and my local gcc tree now has
one extra patch.
Thanks,
Richard.
--
Richard Guenther <richard dot guenther at uni-tuebingen dot de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/