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.
