This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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/



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]