IRA performance regressions on PPC

H.J. Lu hjl.tools@gmail.com
Tue Sep 9 18:25:00 GMT 2008


On Tue, Sep 9, 2008 at 11:13 AM, Luis Machado
<luisgpm@linux.vnet.ibm.com> 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.



More information about the Gcc mailing list