This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: IRA performance regressions on PPC

H.J. Lu wrote:
On Sat, Sep 6, 2008 at 11:24 AM, Luis Machado
<luisgpm@linux.vnet.ibm.com> wrote:
On Sat, 2008-09-06 at 07:49 -0700, H.J. Lu wrote:
On Sat, Sep 6, 2008 at 7:05 AM, Luis Machado <luisgpm@linux.vnet.ibm.com> wrote:
On Fri, 2008-09-05 at 10:34 -0700, H.J. Lu wrote:
On Fri, Sep 5, 2008 at 10:24 AM, Vladimir Makarov <vmakarov@redhat.com> wrote:
H.J. Lu keeps ira-branch merge more fresh than trunk. But the lag is only
I won't apply any non-IRA related patches to ira-merge branch so
that you can get a fair comparison for IRA without regressions
introduced by other changes.

1-3 days usually because gcc community and RA reviewers are very responsive.
 So I don't see a big difference in using ira-merge and trunk.  I'd only
recommend to apply patch

http://gcc.gnu.org/ml/gcc-patches/2008-09/msg00427.html

first because it is critical for performance but I don't know when it will
be approved.

I checked this patch into ira-merge branch.
I've verifired applu and facerec against the ira-merge branch. The
numbers are just as bad as trunk. So, apparently, the last patch didn't
improve performance on those benchmarks.

Any other ideas you'd like me to try on IRA?


Can you verify if your problem is related to

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
Even with data that shows us that the degradation occured between
revisions 139589 and 139590 (139589 showing good numbers and 139590
showing bad numbers), would it still make sense to consider ticket 28690
as the possible reason for this degradation?



My understanding is PowerPC is quite sensitive to choice of register
as shown in PR 28690. IRA merge may make fixes for PR 28690
ineffective. There are a few small testcases in PR 28690. You can
check if those problems in PR 28690 come back due to IRA merge.
Also, IRA disables regmove:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37364

I don't know its impact on PowerPC. Can you try

--- ./regmove.c.regmove	2008-09-06 10:09:43.000000000 -0700
+++ ./regmove.c	2008-09-06 11:34:24.000000000 -0700
@@ -1117,8 +1117,7 @@ regmove_optimize (rtx f, int nregs)

   for (pass = 0; pass <= 2; pass++)
     {
-      /* We need fewer optimizations for IRA.  */
-      if ((! flag_regmove || flag_ira) && pass >= flag_expensive_optimizations)
+      if ((! flag_regmove) && pass >= flag_expensive_optimizations)
 	goto done;

       if (dump_file)
@@ -1167,8 +1166,7 @@ regmove_optimize (rtx f, int nregs)
 		}
 	    }

-	  /* All optimizations important for IRA have been done.  */
-	  if (! flag_regmove || flag_ira)
+	  if (! flag_regmove)
 	    continue;

if (! find_matches (insn, &match))

on the current ira-merge branch.

I can't express how badly I feel this is the wrong direction to be taking. Remove needs to go away and we need to be looking at the root failures rather than re-enabling this crap code in regmove.c

I've got a performance regression as well that ties into the disabling of regmove, but doing a root cause analysis has made it plainly clear that the problem is not regmove, nor IRA, nor the backend port in question. For my specific problem the root cause is actually subreg lowering. While I could fix my regression by twiddling regmove and/or the port itself, neither change is actually solving the problem. I would *STRONGLY* suggest you take the time to do a root cause analysis or at least avoid installing this bandaid patch.

Jeff

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]