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.
> 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.
TBH, the original version of this function looked better to me.
> 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.
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
