[Bug fortran/25620] Missed optimization with power
--- 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
[Bug fortran/25620] Missed optimization with power
--- 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
--- 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
--- 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
--- 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 fortran/25620] Missed optimization with power
--- 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 callpowf movss %xmm0, (%rbx) popq%rbx ret trying to time this with the following fragment: y=0. DO i=1,1000 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
--- 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 callpowf 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
