Understanding IRA

[Jeff Law]

On 11/04/09 10:52, Ian Bolton wrote:
> Hi Jeff,
>
>  From an empirical perspective, the value of your patch is hard to
> determine at this stage - one benchmark improved about 0.5% but others
> have marginally regressed.
>    
It's a hack, no doubt about it.  Your results are about what I expected, 
a few things get better a few things get worse.

The purpose of the patch was twofold.  First, hopefully make reload's 
actions more predictable.  Second hopefully improve the overall code in 
at least some marginal fashion.

I didn't want to burn a lot of time on it since the reload inheritance 
is, IMHO, the biggest ball of hair in reload that I want to kill.  If 
I'm successful in killing the need for reload inheritance, then this 
little hack silently goes away.


>  From an intellectual perspective, however, your patch is clearly a Good
> Thing.  If I am understanding correctly, your aim is to prevent cases
> where reload evicts a pseudo from a register that conflicts with the
> pseudo that we are trying to reload, thereby undoing the clever cost-
> based logic in IRA that gave the register to the current owner in the
> first place?
>    
Basically, yes.  Note that we still allow eviction if no other register 
can be found.

> My guess is that the performance drop could be attributed to reload
> being lucky in some cases and your patch is preventing this luck from
> happening.
Precisely.


>    Whilst I'm more of a risk-taker by nature, my employer
> would prefer more predictable behaviour from its compiler, so we will
> likely commit your patch to our development branch. Thanks very much!
>    
There's definitely a lot more that could be done with this code.  If it 
were going to be around for a while, you'd want to sort the spill 
register array based on a number of criteria.  Part of those criteria 
would be the conflicts & costs recorded by IRA, whether or not the spill 
reg holds a value interesting for this insn, etc.  Given my goals, I 
didn't want to spend that much time on it.


> Is there an ETA on when reload will be gone away? ;-)
>    
It'll be a long time, though I'd like to start staging in pieces of the 
work for 4.6.

jeff