[Bug target/41279] [4.5 Regression] 252.eon performance regression
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-12-16 22:48 --- Seems to be fixed now. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41279
[Bug target/41279] [4.5 Regression] 252.eon performance regression
--- Comment #8 from sje at cup dot hp dot com 2009-10-30 20:42 --- It looks like a patch has been checked in to fix this bug, is there any reason we can't close this defect? -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41279
[Bug target/41279] [4.5 Regression] 252.eon performance regression
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-10-30 22:10 --- It didn't have any effect on the regression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41279
[Bug target/41279] [4.5 Regression] 252.eon performance regression
--- Comment #7 from jakub at gcc dot gnu dot org 2009-09-30 09:58 --- Subject: Bug 41279 Author: jakub Date: Wed Sep 30 09:57:56 2009 New Revision: 152324 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152324 Log: PR target/41279 * cfgloopanal.c (num_loop_insns): Don't increment ninsns for each bb before insn counting loop now that BB_END (bb) is counted. Ensure the return value isn't zero. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgloopanal.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41279
[Bug target/41279] [4.5 Regression] 252.eon performance regression
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41279
[Bug target/41279] [4.5 Regression] 252.eon performance regression
--- Comment #6 from jakub at gcc dot gnu dot org 2009-09-29 21:42 ---
I've looked at what code generation changes the jump from r151310 to r151312
(aka VTA merge) and on eon.cc at -O3 -funroll-loops -fpeel-loops on ia64-linux
the difference is that r151310 unroll something that r151312 does not.
The change that caused this is in num_loop_insns:
@@ -176,8 +176,8 @@ num_loop_insns (const struct loop *loop)
{
bb = bbs[i];
ninsns++;
- for (insn = BB_HEAD (bb); insn != BB_END (bb); insn = NEXT_INSN (insn))
- if (INSN_P (insn))
+ FOR_BB_INSNS (bb, insn)
+ if (NONDEBUG_INSN_P (insn))
ninsns++;
}
free(bbs);
Note that before we didn't count BB_END (bb) insn (well, it is probably counted
in that ninsns++ before the loop), but now we do. Similar change to
average_num_loop_insns changed binsns = 1; before the loop to binsns = 0;, so I
think that:
--- cfgloopanal.c.xx2009-09-29 17:19:59.0 +0200
+++ cfgloopanal.c 2009-09-29 23:30:26.0 +0200
@@ -175,12 +175,11 @@ num_loop_insns (const struct loop *loop)
for (i = 0; i loop-num_nodes; i++)
{
bb = bbs[i];
- ninsns++;
FOR_BB_INSNS (bb, insn)
if (NONDEBUG_INSN_P (insn))
ninsns++;
}
- free(bbs);
+ free (bbs);
return ninsns;
}
is a correct change. No idea whether 252.eon's hot loop is in eon.cc or
elsewhere though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41279
[Bug target/41279] [4.5 Regression] 252.eon performance regression
--- Comment #5 from jamborm at gcc dot gnu dot org 2009-09-08 11:58 --- I tried to reproduce this manually (on thallium:/abuild/mjambor/) but couldn't. I just get the same execution times with or without that patch reverted... I am not sure what this means or how to proceed from here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41279
[Bug target/41279] [4.5 Regression] 252.eon performance regression
--- Comment #4 from jamborm at gcc dot gnu dot org 2009-09-07 12:05 --- Hm, I wonder how come we did not come across this when testing the patch for exactly these kinds of problems in July. Anyway, I will have a look at it. Nevertheless, I believe we should split this bug in two so that we can track the SRA and VTA regressions separately. So unless someone objects or I realize the fix is so trivial it does not really deserve its own PR, I'll create a new Pr for the SRA issue when I come across something interesting. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added CC|mjambor at suse dot cz |jamborm at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41279
[Bug target/41279] [4.5 Regression] 252.eon performance regression
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-09-06 10:17 --- Most of the eon regression was due to the SRA patch. Other changes weren't affected by the SRA patch and so have to be attributed to VTA. See http://gcc.opensuse.org/SPEC/CFP/sb-terbium-head-64/recent.html and http://gcc.opensuse.org/SPEC/CINT/sb-terbium-head-64/recent.html and the bumps around Sep 3rd. I guess VTA wasn't supposed to change code generation at all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41279
[Bug target/41279] [4.5 Regression] 252.eon performance regression
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-05 16:07 --- Likewise effects in SPEC FP. My guess would be scheduler effects of the VTA changes there. While compare-debug tests code generation is the same with -g vs. -g0 nothing checks code generation differences caused by the VTA fixes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41279
[Bug target/41279] [4.5 Regression] 252.eon performance regression
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41279
[Bug target/41279] [4.5 Regression] 252.eon performance regression
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-05 16:14 --- I'll revert the SRA fix on the tester to rule out that change for tonight. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41279
