--- Comment #15 from dominiq at lps dot ens dot fr 2009-08-25 15:30 ---
I think I have made some progress to understand the problem:
(1) The 1,953,139,629 or so calls to pow() are the non optimized base.
(2) For working situations this number is reduced to 63,907,869 or so when
using t
--- Comment #14 from dominiq at lps dot ens dot fr 2009-08-25 12:51 ---
> I don't think the issue is pow expansion.
What I do see from different means is that the number of calls to pow()
increases from 63,907,869 to 1,953,139,629. Since pow() is not exactly cheap, I
think this could
--- Comment #13 from rguenther at suse dot de 2009-08-25 12:40 ---
Subject: Re: Time increase with inlining for the
Polyhedron test air.f90
On Tue, 25 Aug 2009, dominiq at lps dot ens dot fr wrote:
> --- Comment #12 from dominiq at lps dot ens dot fr 2009-08-25 12:30
> ---
--- Comment #12 from dominiq at lps dot ens dot fr 2009-08-25 12:30 ---
>From comment #9, I think inlining is just exposing a latent missed optimization
related to the way the middle end handle pow(). This is why I changed the
summary.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-08-25 12:22
---
We clone quite a few functions with -fwhole-file but appearantly we fail to
apply constant propagation for &CONST_DECL arguments which is a pity. In fact
we seem to clone them without any change.
--
rguenth at
--- Comment #9 from dominiq at lps dot ens dot fr 2009-08-25 11:55 ---
I see a similar slowdown with the patch in
http://gcc.gnu.org/ml/fortran/2009-08/msg00361.html (see
http://gcc.gnu.org/ml/fortran/2009-08/msg00377.html). I suspect it is related
to pr41098, but I don't know how to sho
--- Comment #8 from burnus at gcc dot gnu dot org 2009-07-13 15:29 ---
(Not restricted to Darwin, happens also on x86-64-linux.)
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from dominiq at lps dot ens dot fr 2009-05-22 20:52 ---
I had a closer look at the code and found that the inner loop
DO k = 0 , Np(i)
uxt = uxt + D(j,k+1)*U(jmin+k,jm)
ENDDO
is unrolled 8 times, but Np(i) is always equal t
--- Comment #6 from dominiq at lps dot ens dot fr 2009-05-22 20:41 ---
Created an attachment (id=17904)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17904&action=view)
air.s file for i686-apple-darwin9 compiled with -m64 -O3 -ffast-math
-funroll-loops -fwhole-file
--
http://g
--- Comment #5 from dominiq at lps dot ens dot fr 2009-05-22 20:39 ---
Created an attachment (id=17903)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17903&action=view)
air.s file for i686-apple-darwin9 compiled with -m64 -O3 -ffast-math
-funroll-loops
--
http://gcc.gnu.org/bu
--- Comment #4 from dominiq at lps dot ens dot fr 2009-05-12 16:18 ---
Assembly code for the inlined inner loop:
L123:
movsd (%rdx), %xmm15
movsd 8(%rdx), %xmm6
mulsd (%rax), %xmm15
mulsd 1200(%rax), %xmm6
movsd 16(%rdx), %xmm4
m
--- Comment #3 from rguenther at suse dot de 2009-05-12 14:47 ---
Subject: Re: Time increase with inlining for the
Polyhedron test air.f90
On Tue, 12 May 2009, dominiq at lps dot ens dot fr wrote:
> --- Comment #2 from dominiq at lps dot ens dot fr 2009-05-12 13:23
> ---
>
--- Comment #2 from dominiq at lps dot ens dot fr 2009-05-12 13:23 ---
> decreasing --param hot-bb-frequency-fraction might help in this case.
I have tried --param hot-bb-frequency-fraction=1 (which seems the smallest
possible value, see pr40119), but it did not changed anything.
What
--- Comment #1 from hubicka at gcc dot gnu dot org 2009-05-12 11:52 ---
Hmm, the inlined functions has loop depth of 4, that makes it predicted to
iterate quite few times. My guess would be that inlining increases loop depth
that in turn makes GCC to conclude that one of loops that are i
14 matches
Mail list logo
