[PATCH SMS 2/2, RFC] Register pressure estimation for the partial schedule (re-submission)

[Ayal Zaks]

On Mon, Jan 2, 2012 at 3:30 PM, Richard Sandiford
<rdsandiford@googlemail.com> wrote:
> Ayal Zaks <ayal.zaks@gmail.com> writes:
>> +  for (i = 0; i < ira_pressure_classes_num; i++)
>> +    {
>> +      enum reg_class pressure_class;
>> +
>> +      pressure_class = ira_pressure_classes[i];
>> +
>> +      if (max_reg_pressure[pressure_class] == 0)
>> +     continue;
>> +
>> +      if (dump_file)
>> +     fprintf (dump_file, "%s=%d  %d ", reg_class_names[pressure_class],
>> +              max_reg_pressure[pressure_class],
>> +              ira_available_class_regs[pressure_class]);
>> +
>> +      if (max_reg_pressure[pressure_class]
>> +       > ira_class_hard_regs_num[pressure_class])
>> +     {
>> +       if (dump_file)
>> +         fprintf (dump_file, "(pressure)\n");
>> +
>> +       pressure_p = true;
>>
>> you can "break;" now.
>
> FWIW, I thought the same thing at first, but I think Revital's way is better.
> It's nice to know when looking at dumps whether there is excess pressure
> in more than one class.  This isn't performance-critical code after all.
>

ok

>> however, you have everything setup to compute the amount of spill, so
>> suggest to do the following instead:
>>
>>           pressure += max_reg_pressure[pressure_class]
>>                       - ira_class_hard_regs_num[pressure_class]);
>>
>> or better call the variable "spillage" instead of "pressure", and
>> return it. Current use will only check if it's zero or positive.
>
> I read this suggestion in the same way as Revital seems to have done:
> that we sum the pressure change over all classes.  But that isn't the idea.
> Using N too many registers in one pressure class cannot be mitigated by
> leaving N registers in another pressure class unused.
>

of-course (wasn't thinking of spilling from one register file to
another); meant to suggest doing:

if (max_reg_pressure[pressure_class] > ira_class_hard_regs_num[pressure_class])
  spillage += max_reg_pressure[pressure_class] -
ira_class_hard_regs_num[pressure_class]);


> TBH, the original version of this function looked better to me.
>

ok, it would surely suffice for now.


>> Future use, as discussed offline, should compare this to the amount of
>> spillage the original loop (w/o modulo-scheduling) is expected to
>> have.
>
> I wonder if that's really worth pursuing though.  For one thing,
> we've no control over where the spill code is going to be inserted,
> so the final ii is going to be a little arbitrary.  That's less of a
> problem without SMS because we're able to reschedule the code after
> register allocation in order to move spills around.

Indeed; that's the main motivation for the second sched pass.

>
> For another thing, the pressure of the original (unscheduled) code isn't
> necessarily indicative of what can be achieved by the normal scheduler
> with something like -fsched-pressure.  We can't assume that the original
> block has minimum pressure.
>
> If we're serious about wanting to use SMS in high-pressure loops,
> perhaps we should consider trying to split live ranges in SMS itself.
> I'm not sure it makes sense to leave an SMSed loop that we "know"
> is going to need spill code.
>
> Richard

Agreed. Suggest to have concrete testcases guide further development.
Thanks,
Ayal.