[RFC][PATCH IRA] Fix PR87507, IRA unnecessarily uses non-volatile registers during register assignment
Vladimir Makarov
vmakarov@redhat.com
Tue Oct 9 23:39:00 GMT 2018
On 10/08/2018 03:36 PM, Peter Bergner wrote:
> PR87507 shows a problem where IRA assigns a non-volatile TImode reg pair to
> a pseudo when there is a volatile reg pair available to use. This then
> causes us to emit save/restore code for the non-volatile reg usage.
>
> The problem here is that the only volatile reg pair that is available is an
> odd/even reg pair (r7,r8) and ira-costs.c:ira_tune_allocno_costs() disparages
> odd/even reg pairs by increasing their cost. That's fine, but an even/odd
> non-volatile reg pair should still be more expensive than an odd/even reg
> pair given the save/restore that we'd need to use it. However, the costs
> used in assign_hard_reg() show that non-volatile reg pair (r30,r31) is
> cheaper than odd/even reg pair (r7,r8) (15 versus 1000). That's a huge
> disparity in costs, so looking at where the non-volatile cost comes from,
> it comes from the code below in ira-color.c:assign_hard_reg():
>
> if (!HONOR_REG_ALLOC_ORDER)
> {
> if ((saved_nregs = calculate_saved_nregs (hard_regno, mode)) != 0)
> /* We need to save/restore the hard register in
> epilogue/prologue. Therefore we increase the cost. */
> {
> rclass = REGNO_REG_CLASS (hard_regno);
> add_cost = ((ira_memory_move_cost[mode][rclass][0]
> + ira_memory_move_cost[mode][rclass][1])
> * saved_nregs / hard_regno_nregs (hard_regno,
> mode) - 1);
> cost += add_cost;
> full_cost += add_cost;
> }
> }
>
> I'm not sure I understand the "* saved_nregs / h_r_n (h_r, m) - 1" part
> of the calculation. If saved_nregs is the number of hard regs that
> need to be saved for hard_regno in mode MODE (ie, we don't need to
> save a hard reg if it's already been saved, etc.), then why aren't we
> just multiplying by saved_nregs? The other problem I see here is
> that we're not scaling the cost by the basic block frequency of the
> prologue/epilogue, which is what is causing the non-volatile reg
> cost to be so low compared to the odd/even volatile reg use, which
> is scaled. However, even if I fix that, improve_allocation() comes
> along and undoes it, because it too does not correctly compute the
> cost of non-volatiles, so that seems to me that it needs fixing too.
It would be right if we have only one pseudo using non-volatile regs.Â
But at this stage we don't know how many pseudos will use the
non-volatile reg. Once the non-volotile reg is used, it is free for all
other pseudo uses (and they can be in hot regions as loops).
The costs were heuristically tuned on SPEC2000 on x86/x86-64. As the
functions are bigger (now we have aggressive inlining), the only small
increase for non-volatile reg works better. That is why I don't like
small test RA PRs, the heuristics can be bad for them but they can work
better for real programs. When I change this code, I always check SPEC
because sometimes the results are opposite to the expected ones.
May be you could find better heuristics which works for small and big
functions.
> I have the following work in progress patch I'd like some comments on.
> Am I on the right track here? I noticed that assign_hard_reg() tracks
> min_cost and min_full_cost, but min_cost is actually never used for
> anything other than setting min_cost, so I removed it. I also don't
> understand why we don't charge non-volatile usage for targets that define
> HONOR_REG_ALLOC_ORDER. Why shouldn't we always account for save/restore
> of non-volatile reg usage?
Once min_cost was used for different heuristics. Still it is useful for
debugging because full_cost calculations is very complicated (it is
affected by conflict allocnos preferences and allocnos connected
directly and indirectly by copies). Min_cost can be useful in debugging
to see the picture because its calculation is more straightforward.
A few years ago IRA did not use HONOR_REG_ALLOC_ORDER but people filled
a PR (I don't remember the number) and that is what behaviour they
exactly wanted.
More information about the Gcc-patches
mailing list