On Mon, Jan 2, 2012 at 3:30 PM, Richard Sandiford
<rdsandif...@googlemail.com> wrote:
> Ayal Zaks <ayal.z...@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.
