[Bug libstdc++/11706] std::pow(T, int) implementation pessimizes code

[rguenth at tat dot physik dot uni-tuebingen dot de]

------- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de  2003-11-13 21:42 -------
Subject: Re:  std::pow(T, int) implementation pessimizes
 code

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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11706