IRA performance regressions on PPC

Jeff Law law@redhat.com
Sat Sep 6 21:22:00 GMT 2008


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



More information about the Gcc mailing list