--- Comment #16 from hjl at lucon dot org 2007-06-23 14:46 ---
> HJ, what is the situation w.r.t performance regression after the above patch
> was committed to SVN?
>
I think it still needs tuning. I got the following on Linux/Intel64:
(r125740 - r121297)/r1
--- Comment #15 from ubizjak at gmail dot com 2007-06-23 10:00 ---
(In reply to comment #14)
> Subject: Bug 31090
>
> Author: dnovillo
> Date: Wed Apr 11 17:14:06 2007
> New Revision: 123719
>
HJ, what is the situation w.r.t performance regression after the above patch
was committed t
--- Comment #14 from dnovillo at gcc dot gnu dot org 2007-04-11 17:14
---
Subject: Bug 31090
Author: dnovillo
Date: Wed Apr 11 17:14:06 2007
New Revision: 123719
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123719
Log:
PR 30735
PR 31090
* doc/invoke.t
--- Comment #13 from dnovillo at redhat dot com 2007-03-10 00:07 ---
Subject: Re: Revision 121302 causes 30% performance
regression
hjl at lucon dot org wrote on 03/09/07 19:04:
> --param max-aliased-vops=100 works:
>
OK, thanks. I'll add this PR to the mix then.
--
http://gcc
--- Comment #12 from hjl at lucon dot org 2007-03-10 00:04 ---
--param max-aliased-vops=100 works:
[EMAIL PROTECTED] 597]$ make
/usr/gcc-next/bin/gfortran -c -O2 --param max-aliased-vops=100 -o 301.o
test597.f90
/usr/gcc-4.3/bin/gfortran -o 301 301.o -Wl,-rpath,/usr/gcc-4.3/lib64
/usr/g
--- Comment #11 from dnovillo at gcc dot gnu dot org 2007-03-09 23:53
---
I'm already handling this family of performance problems. I need a few more
days to finish the WIP patch I have. In the meantime, see if increasing
--param max-aliased-vops works around the problem.
--
dnov
--- Comment #10 from dberlin at gcc dot gnu dot org 2007-03-09 23:48
---
(In reply to comment #7)
> The obvoious difference is more precise alias information:
>
> -bar: Maximum number of VOPS needed per statement: 80
> +bar: Maximum number of VOPS needed per statement: 71
See, it was
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-03-09 23:17 ---
I didn't complain about register pressure. You need to get a thicker skin.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31090
--- Comment #8 from pinskia at gmail dot com 2007-03-09 23:05 ---
Subject: Re: Revision 121302 causes 30% performance regression
On 9 Mar 2007 23:00:55 -, rguenth at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
> Other than that, more precise alias information
> can cause more
On 9 Mar 2007 23:00:55 -, rguenth at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
Other than that, more precise alias information
can cause more register pressure, too.
Fix the register allocator instead of complaining about this issue. I
am sorry but if people want a compiler which wo
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-03-09 23:00 ---
The obvoious difference is more precise alias information:
-bar: Maximum number of VOPS needed per statement: 80
+bar: Maximum number of VOPS needed per statement: 71
(and the resulting different partitioning).
Wh
--- Comment #6 from hjl at lucon dot org 2007-03-09 17:57 ---
Created an attachment (id=13181)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13181&action=view)
Dumps of -fdump-tree-alias-vops-details-blocks-stats
121301 is from revision 121301 and 121302 is from revision 121302.
--- Comment #5 from dberlin at gcc dot gnu dot org 2007-03-09 17:51 ---
Subject: Re: Revision 121302 causes 30% performance regression
Could you attach dumps for fdump-tree-alias-vops-details-blocks-stats
(tarr'ing up the resulting dumps is fine) for before and after?
I don't have a c
--- Comment #4 from hjl at lucon dot org 2007-03-09 17:40 ---
Created an attachment (id=13180)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13180&action=view)
A breakdown testcase
xxx.f90 is the problem. -fdump-tree-all shows that revision 121302
generates very different alias in
--- Comment #3 from hjl at lucon dot org 2007-03-09 17:11 ---
Gcc 4.3 revision 122738 has the same issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31090
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-03-09 10:32 ---
It looks like a no-op change. For reference:
--- ChangeLog (revision 121301)
+++ ChangeLog (revision 121302)
@@ -1,3 +1,41 @@
+2007-01-28 Daniel Berlin <[EMAIL PROTECTED]>
+
+ * tree.h (struct tree_memo
--- Comment #1 from hjl at lucon dot org 2007-03-08 20:04 ---
Created an attachment (id=13173)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13173&action=view)
A testcase
/usr/gcc-next/bin/gfortran -c -O2 -o 301.o test597.f90
/usr/gcc-next/bin/gfortran -o 301 301.o -Wl,-rpath,/usr
17 matches
Mail list logo
