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

["rguenth at tat dot physik dot uni-tuebingen dot de" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de  2003-12-06 18:26 -------
Subject: Re:  std::pow(T, int) implementation pessimizes
 code

On Sat, 5 Dec 2003, bkoz at gcc dot gnu dot org wrote:

>
> ------- Additional Comments From bkoz at gcc dot gnu dot org  2003-12-05 23:52 -------
>
> Can you provide a patch for this, or give current status? Have you asked Roger
> Sayle about this, who seems to be the guru of builtin math functions? There also
> are changes to std_cmath.h for pow, see:
>
> 2003-11-15  Roger Sayle  <roger@eyesopen.com>
>
> 	* include/c_std/std_cmath.h: Don't import C99's float transcendentals
> 	into the __gnu_cxx::__c99_binding namespace.
> 	(acos, asin, atan, atan2, ceil, cosh, exp, floor, fmod, frexp,
> 	ldexp, log, log10, modf, pow, sinh, tan, tanh): Implement using
> 	GCC's math builtins, i.e. __builtin_foo.
> 	* libmath/stubs.c (acosf, acosl, asinf, asinl, atanf, atanl,
> 	ceilf, ceill, floorf, floorl, fmodf, fmodl, frexpf, frexpl,
> 	ldexpf, ldexpl, modff, modfl): Provide stub implementations.

Uh, now even the ::pow(x, 2) call creates unoptimized code...:

_Z3food:
.LFB162:
        pushl   %ebp    #
.LCFI2:
        xorl    %edx, %edx      #
        movl    %esp, %ebp      #,
.LCFI3:
        subl    $24, %esp       #,
.LCFI4:
        movl    $1073741824, %eax       #,
        fldl    8(%ebp) # x
        movl    %edx, 8(%esp)   #,
        movl    %eax, 12(%esp)  #,
        fstpl   (%esp)  #
        call    pow     #
        leave
        ret

the std::pow(x, 2) one is still the same. Not quite uptodate
g++-3.4 (GCC) 3.4 20031124 (experimental)

> Can we get this resolved, folks? I think all that needs to be done now is
> examine cmath.tcc for inline-ability (ie, is __cmath_power to be inlined now?)
> Please let me know how I can help.

Inlining __cmath_power won't help, as gcc is unable to optimize the loop
in it which has a non-linear biv. Some time ago it did help to call
__builtin_pow() from inside the integer overloads of pow, but I suspect
this is no longer true. Another possibility is to use __builtin_constant()
to check for constant exponent and manually optimize for this.

Btw., the ::pow() behavior is now a regression towards gcc 3.3

Richard.


-- 


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