Jeff Law wrote:
On 11/03/09 09:29, Ian Bolton wrote:
Hi again, Vladimir,
I am pleased to report some performance improvements after altering
ira-costs.c. A key benchmark for us has improved by 5%.
Specifically, in record_reg_classes(), after the alt_cost has been
calculated and it will be applied to pp->mem_cost and pp->cost[k], I
check whether this particular operand wanted one of our BOTTOM_REGS
(r0-r15) and I further increase the pp->mem_cost by an arbitrary
amount and also increase pp->cost[k] by an arbitrary amount if k
does not represent the BOTTOM_REGS class. My aim here is to nudge
IRA in the right direction for operands that just want BOTTOM_REGS.
After experimenting with different values for my "arbitrary
amounts", I discovered some that successfully made IRA more likely
to give BOTTOM_REGS to those instructions/operands that want
BOTTOM_REGS, since any other regs and memory ended up with high
enough costs for IRA to try and avoid using them.
I have included a snippet from my version of record_reg_classes()
below:
What I don't understand at this point is why the current mechanisms in
IRA aren't showing a lower cost for using BOTTOM_REGS (or a higher
cost for TOP_REGS). i.e. I don't think any of this should be
necessary as IRA should already be doing something similar.
This may be a case where your backend hasn't indicated that TOP_REGS
has a higher cost than BOTTOM_REGS in particular situations.
I am agree with Jeff. It is hard to understand what you are doing
without the architecture knowledge and some macro values in your port
(IRA_COVER_CLASSES, MEMORY_MOVE_COST, and REGISTER_MOVE_COST).
I'd also add that besides right macro value definitions, you could use
insn alternative hints near register constraints like ? or even *.
