H.J. Lu wrote:
On Sat, Sep 6, 2008 at 11:24 AM, Luis Machado
<[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
