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.
jeff
