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.