Re: Understanding IRA

[Vladimir Makarov <vmakarov@redhat.com>]

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