On Tue, Sep 9, 2008 at 11:13 AM, Luis Machado <[EMAIL PROTECTED]> wrote: > On Mon, 2008-09-08 at 09:47 -0400, Vladimir Makarov wrote: >> Jeff Law wrote: >> > H.J. Lu wrote: >> >> 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. >> > >> I am agree with Jeff. IRA was designed to replace most of regmove. It >> has ability to do what regmove does. Switching on regmove besides >> making RA slower only hides what is wrong with IRA. >> >> Although, it would be interesting to see what regmove can give to IRA. >> > > Upon further investigation on facerec's regression, it looks like the > code generated by the IRA-enabled gcc has many more spills than the one > with a disabled IRA, twice or sometimes three times more. > > I'm trying to reduce the testcase a bit further so it's simpler to > analyse. >
We also noticed that IRA might cause unnecessary memory accesses on x86: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37437 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37364 -- H.J.
