Jeff Law wrote:
Dave Hudson wrote:
I would have hoped that having done the analysis early on that the
register allocator would try to allocate from the preferred register
class rather than the cover class but it seems that doesn't happen?
So you're saying that the register preferences look reasonable, but in
low pressure situations the allocator appears to largely ignore the
preferred register class?
I did some more digging into this over the last couple of days and it
seems that the RA appears to over-emphasize the benefits of propagating
hard regs - in this case one or more hard regs that are holding incoming
function arguments. The RA ends up believing that the hard reg (a data
register here) has the same cost as copying and using an address
register, but this means we end up with reload trying to clean up the
result after the RA has assigned a register that can't actually be used
for a MEM.
As an experiment I modified the weighting for a MEM in
record_operand_costs(), multiplying frequency by 33/16 instead of 2 and
that shifts the balance sufficiently to get the correct choice.
Obviously thought that's not a solution - it just indicates something
about the problem.
Curiously though (and seemingly quite unrelated to what I'm seeing) I
did noticed that if the RA chooses to use a callee-saved register it
only adjusts the cost associated with that register by a very small
amount - the comment in assign_hard_reg() in ira-color.c mentions the
need to increase the cost of the hard reg because of the need to
save/restore in the prologue/epilogue (actually it appears to have these
back-to-front in the comment), but the value is never adjusted by any
frequency, just the sum of the 2 memory move costs - 1.
It might help if you could provide some debugging dumps. The .ira dump
in particular contains a wealth of information about the decisions the
allocator is making.
They don't show anything terribly helpful unfortunately because they
don't appear to show any of the costs associated with the hard regs - I
ended up instrumenting the code to work out what I've found so far.
Anyone have any ideas other than writing a pass that runs before
reload and tries to fix this up?
The first thing is to understand why IRA is doing what it's doing.
We're generally better off generating a good allocation rather than
trying to clean it up post-allocation.
No arguments there :-)
Cheers,
Dave
