This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/41279] [4.5 Regression] 252.eon performance regression
- From: "jakub at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 29 Sep 2009 21:42:21 -0000
- Subject: [Bug target/41279] [4.5 Regression] 252.eon performance regression
- References: <bug-41279-10053@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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.xx 2009-09-29 17:19:59.000000000 +0200
+++ cfgloopanal.c 2009-09-29 23:30:26.000000000 +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