[Bug tree-optimization/25620] New: Missed optimisation with power

[Bug tree-optimization/25620] New: Missed optimisation with power

[jv244 at cam dot ac dot uk]

The following is not optimised (I tested current 4.2) with -ffast-math -O2 (or
any of the other options I tried):

SUBROUTINE S41(a,b,c,N)
 IMPLICIT NONE
 integer :: N
 real*8  :: a(N),b(N),c(N)
 integer :: i
 c=0.0D0
 DO i=1,N
   b(i)=b(i)+a(i)**(4.0D0/3.0D0)
   c(i)=c(i)+a(i)**(2.0D0/3.0D0)
 ENDDO
END SUBROUTINE

This could be written as 

SUBROUTINE S42(a,b,c,N)
 IMPLICIT NONE
 integer :: N
 real*8  :: a(N),b(N),c(N),tmp,tmp2,tmp4
 real*8, parameter :: p=1.0D0/3.0D0
 integer :: i
 c=0.0D0
 DO i=1,N
   tmp=a(i)**p ! could even be done with a cube root
   tmp2=tmp*tmp
   tmp4=tmp2*tmp2
   b(i)=b(i)+tmp4
   c(i)=c(i)+tmp2
 ENDDO
END SUBROUTINE

saving at least one expensive power computation. Also replacing the cube root
with specific code would be nice.


-- 
           Summary: Missed optimisation with power
           Product: gcc
           Version: 4.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jv244 at cam dot ac dot uk


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

[Bug tree-optimization/25620] Missed optimization with power (only with -ffast-math)

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2006-01-06 14:07 -------
Confirmed.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2006-01-06 14:07:43
               date|                            |
            Summary|Missed optimisation with    |Missed optimization with
                   |power                       |power (only with -ffast-
                   |                            |math)


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

[Bug tree-optimization/25620] Missed optimization with power

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2006-01-13 16:37 -------
Actually I take back my comment about with -ffast-math only as Fortran rules
are way different from C and C++.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Missed optimization with    |Missed optimization with
                   |power (only with -ffast-    |power
                   |math)                       |


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

[Bug fortran/25620] Missed optimization with power

[rguenth at gcc dot gnu dot org]

------- Comment #3 from rguenth at gcc dot gnu dot org  2006-01-13 16:44 -------
This needs to be done by the frontend, as the folded 2/3 or 4/3 is not exactly
representable in the target FP format (and such cannot be checked for).  Making
this a frontend bug, rather than just closing as WONTFIX ;)


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|tree-optimization           |fortran


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

[Bug fortran/25620] Missed optimization with power

[jv244 at cam dot ac dot uk]

------- Comment #4 from jv244 at cam dot ac dot uk  2006-01-13 17:33 -------
(In reply to comment #3)
> This needs to be done by the frontend, as the folded 2/3 or 4/3 is not exactly
> representable in the target FP format (and such cannot be checked for).  Making
> this a frontend bug, rather than just closing as WONTFIX ;)

Without fully understanding the above in all details.

some target FP format might still have that 2./3. == 2 * 1./3. ?

Furthermore, I would think that under -ffast-math these kind of transformations
should be allowed if these equalities hold 'at machine precision'. E.g.

x**p is replaced by cuberoot(p) if p is the FP number that is closest to 1./3.


-- 


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

[Bug fortran/25620] Missed optimization with power

[jv244 at cam dot ac dot uk]

------- Comment #5 from jv244 at cam dot ac dot uk  2006-01-13 17:38 -------
I just note that ifort generates this in the asm 

for  a**(1./3.):
call      cbrtf

and for a**(1.D0/3.D0)
call      cbrt


-- 


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

[Bug fortran/25620] Missed optimization with power

[jv244 at cam dot ac dot uk]

------- Comment #6 from jv244 at cam dot ac dot uk  2006-01-13 18:15 -------
another example:

REAL*8 :: a,b
read(6,*) a
b=a**(3.D0/2.D0)
write(6,*) b
END

gets computed by ifort as

b=a*sqrt(a)

but this is also turned into pow by gfortran at -O3 -ffast-math


-- 


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

[Bug fortran/25620] Missed optimization with power

[rguenth at gcc dot gnu dot org]

------- Comment #7 from rguenth at gcc dot gnu dot org  2006-01-13 18:42 -------
Looking at how we deal with all this, we seem to like pow() very much during
folding, even doing the reverse transformations you suggest.  The
transformation
back to sqrt ( x**N ) with N being an integer could be done by
expand_builtin_pow
in case that computation of sqrt is cheap.  Other than that, exposing integer
powers is only a win if theres some CSE possibility.


-- 


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

[Bug fortran/25620] Missed optimization with power

[kargl at gcc dot gnu dot org]

------- Comment #8 from kargl at gcc dot gnu dot org  2006-01-13 19:58 -------
Technically, all of the transformations noted by Joost are
a violation of the Fortran standard with the possible 
exception of the transformation of x**(1./3.) to cbrt(x).
See 7.1.7.2.


-- 

kargl at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu dot org


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

[Bug fortran/25620] Missed optimization with power

[jv244 at cam dot ac dot uk]

------- Comment #9 from jv244 at cam dot ac dot uk  2006-09-04 14:10 -------
(In reply to comment #7)
> Looking at how we deal with all this, we seem to like pow() very much during
> folding, even doing the reverse transformations you suggest.  The
> transformation
> back to sqrt ( x**N ) with N being an integer could be done by
> expand_builtin_pow
> in case that computation of sqrt is cheap.  Other than that, exposing integer
> powers is only a win if theres some CSE possibility.

Despite this PR being a bit old, I'd like to add another (similar example, also
from real code) where other compilers generate much better code:

subroutine t(x)
 x=x**1.5
end subroutine t

pgf90:
# lineno: 0
        sqrtss  (%rdi), %xmm0
        mulss   (%rdi), %xmm0
        movss   %xmm0, (%rdi)

gfortran -S -O3 -ffast-math:
        movss   (%rdi), %xmm0
        movq    %rdi, %rbx
        movss   .LC0(%rip), %xmm1
        call    powf
        movss   %xmm0, (%rbx)
        popq    %rbx
        ret

trying to time this with the following fragment:
y=0.
DO i=1,10000000
 x=i
 y=y+x**1.5
ENDDO
write(6,*) y
END

pgf90 is about 10 times faster than gfortran


-- 


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

[Bug fortran/25620] Missed optimization with power

[rguenther at suse dot de]

------- Comment #10 from rguenther at suse dot de  2006-09-04 14:17 -------
Subject: Re:  Missed optimization with power

On Mon, 4 Sep 2006, jv244 at cam dot ac dot uk wrote:

> 
> 
> ------- Comment #9 from jv244 at cam dot ac dot uk  2006-09-04 14:10 -------
> (In reply to comment #7)
> > Looking at how we deal with all this, we seem to like pow() very much during
> > folding, even doing the reverse transformations you suggest.  The
> > transformation
> > back to sqrt ( x**N ) with N being an integer could be done by
> > expand_builtin_pow
> > in case that computation of sqrt is cheap.  Other than that, exposing integer
> > powers is only a win if theres some CSE possibility.
> 
> Despite this PR being a bit old, I'd like to add another (similar example, also
> from real code) where other compilers generate much better code:
> 
> subroutine t(x)
>  x=x**1.5
> end subroutine t
> 
> pgf90:
> # lineno: 0
>         sqrtss  (%rdi), %xmm0
>         mulss   (%rdi), %xmm0
>         movss   %xmm0, (%rdi)
> 
> gfortran -S -O3 -ffast-math:
>         movss   (%rdi), %xmm0
>         movq    %rdi, %rbx
>         movss   .LC0(%rip), %xmm1
>         call    powf
>         movss   %xmm0, (%rbx)
>         popq    %rbx
>         ret

This should be doable from expand_builtin_pow if we have an optab
for the sqrt computation.

Richard.


-- 


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

[Bug fortran/25620] Missed optimization with power

[rguenth at gcc dot gnu dot org]

------- Comment #11 from rguenth at gcc dot gnu dot org  2006-11-04 15:01 -------
Mine.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2006-04-23 18:02:00         |2006-11-04 15:01:43
               date|                            |


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

[Bug middle-end/25620] Missed optimization with power

[patchapp at dberlin dot org]

------- Comment #12 from patchapp at dberlin dot org  2006-11-05 20:39 -------
Subject: Bug number PR25620

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg00216.html


-- 


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

[Bug middle-end/25620] Missed optimization with power

[patchapp at dberlin dot org]

------- Comment #13 from patchapp at dberlin dot org  2006-11-26 14:30 -------
Subject: Bug number PR25620

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01758.html


-- 


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

[Bug middle-end/25620] Missed optimization with power

[rguenth at gcc dot gnu dot org]

------- Comment #14 from rguenth at gcc dot gnu dot org  2006-11-27 11:38 -------
Subject: Bug 25620

Author: rguenth
Date: Mon Nov 27 11:38:42 2006
New Revision: 119248

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119248
Log:
2006-11-27  Richard Guenther  <rguenther@suse.de>

        PR middle-end/25620
        * builtins.c (expand_builtin_pow): Optimize non integer valued
        constant exponents using sqrt or cbrt if possible.  Always fall back
        to expanding via optabs.

        * gcc.target/i386/pow-1.c: New testcase.
        * gcc.dg/builtins-58.c: Likewise.

Added:
    trunk/gcc/testsuite/gcc.dg/builtins-58.c
    trunk/gcc/testsuite/gcc.target/i386/pow-1.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/builtins.c
    trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/25620] Missed optimization with power

[rguenth at gcc dot gnu dot org]

------- Comment #15 from rguenth at gcc dot gnu dot org  2006-11-27 11:52 -------
Fixed (partly) on the mainline.  We can now expand pow (x, n/2) and pow (x,
n/3)
properly using sqrt and/or cbrt, but cbrt is not available from the fortran
frontend (it misses to define __builtin_cbrt).


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|rguenth at gcc dot gnu dot  |unassigned at gcc dot gnu
                   |org                         |dot org
             Status|ASSIGNED                    |NEW
          Component|middle-end                  |fortran


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

[Bug fortran/25620] Missed optimization with power

[jv244 at cam dot ac dot uk]

------- Comment #16 from jv244 at cam dot ac dot uk  2006-11-27 16:49 -------
(In reply to comment #15)
> Fixed (partly) on the mainline.  We can now expand pow (x, n/2) and pow (x,
> n/3)
> properly using sqrt and/or cbrt, but cbrt is not available from the fortran
> frontend (it misses to define __builtin_cbrt).
> 
Thanks Richard, for this patch, and your other efforts to improve performance
for number crunching applications... 
hopefully the fortran frontend will be fixed as well.


-- 


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

[Bug fortran/25620] Missed optimization with power

[fxcoudert at gcc dot gnu dot org]

------- Comment #17 from fxcoudert at gcc dot gnu dot org  2007-01-22 22:02 -------
cbrt is now available in the front-end (among others), thanks again to Richard!

Closing this PR, as the optimization appears to be working fully:

$ cat a.f90
REAL*8 :: a(6),b(6)
read(*,*) a(:)
b(1)=a(1)**(1.D0/3.D0)
b(2)=a(2)**(1/3.D0)
b(3)=a(3)**(2.D0/3.D0)
b(4)=a(4)**(1/2.D0)
b(5)=a(5)**(1.D0/2.D0)
b(6)=a(6)**(3.D0/2.D0)
write(*,*) b
END
$ gfortran -O2 -ffast-math a.f90 -S
$ grep -c pow a.s                  
0
$ grep -c cbrt a.s                 
3
$ grep -c sqrt a.s                 
3


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


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

[Bug fortran/25620] Missed optimization with power

[vincent at vinc17 dot org]

------- Comment #18 from vincent at vinc17 dot org  2010-03-18 14:37 -------
The patch affected C, where the transformation of pow(x, 0.5) into sqrt(x) is
incorrect. See PR 43419.


-- 

vincent at vinc17 dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vincent at vinc17 dot org


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