gcc

[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: Any ideas how to get the IRA to choose one subclass of registers over another in the same cover class? Dave Hudson Fri Jun 26 08:00:51 2009

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