Re: Understanding IRA

[Jeff Law <law at redhat dot com>]

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