This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [Bug libstdc++/11706] std::pow(T, int) implementation pessimizescode
- From: Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>
- To: gdr at integrable-solutions dot net <gcc-bugzilla at gcc dot gnu dot org>
- Cc: gcc at gcc dot gnu dot org
- Date: Thu, 13 Nov 2003 22:37:47 +0100 (CET)
- Subject: Re: [Bug libstdc++/11706] std::pow(T, int) implementation pessimizescode
- References: <20030729120327.11706.rguenth@tat.physik.uni-tuebingen.de><20030929161707.29290.qmail@sources.redhat.com>
On Mon, 29 Sep 2003, gdr at integrable-solutions dot net wrote:
> ------- Additional Comments From gdr at integrable-solutions dot net 2003-09-29 16:17 -------
> Subject: Re: std::pow(T, int) implementation pessimizes code
>
> "rguenth at tat dot physik dot uni-tuebingen dot de" <gcc-bugzilla@gcc.gnu.org> writes:
>
> | It is - see line 556 in <cmath> which unconditionally uses ::pow. The
>
> It is a bug, feel free to submit a due PR :-)
Can we please have progress on the std::pow(T, int) issue? For those who
dont remember, look at the code generated for std::pow(x, 2) compared to
::pow(x, 2).
The most clean solution would be __builtin_powi(), __builtin_powfi(), __builtin_powli()
functions, but just replacing __cmath_power() usage in
cmath.h:__pow_helper() by ::pow() or __builtin_pow() for constant
exponents solves the optimization issues for gcc 3.4. So __pow_helper()
would look like:
template<typename _Tp>
inline _Tp
__pow_helper(_Tp __x, int __n)
{
if (__builtin_constant_p(__n))
return ::pow(__x, __n);
else
return __n < 0
? _Tp(1)/__cmath_power(__x, -__n)
: __cmath_power(__x, __n);
}
or replace the uses of __pow_helper() in the pow() overloads according to
the above transformation (using appropriate ::pow(), ::powf() and ::powl()
if available).
Thanks,
Richard.