Happened between revs 151305 (good) and 151347 (bad). This range includes the VTA merge and the SRA useless transformation fix.
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".
I'll revert the SRA fix on the tester to rule out that change for tonight.
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.
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.
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.
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.
Subject: Bug 41279 Author: jakub Date: Wed Sep 30 09:57:56 2009 New Revision: 152324 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=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
It looks like a patch has been checked in to fix this bug, is there any reason we can't close this defect?
It didn't have any effect on the regression.
Seems to be fixed now.