Re: [PATCH] Fix IRA register preferencing

[Jeff Law <law at redhat dot com>]

On 12/10/14 06:26, Wilco Dijkstra wrote:
> If recomputing is best does that mean that record_reg_classes should not
> give a boost to the preferred class in the 2nd pass?
Perhaps.  I haven't looked deeply at this part of IRA.  I was relaying 
my experiences with (ab)using the ira-reload callbacks to handle 
allocation after splitting -- where getting the costs and classes 
updated in a reasonable manner was clearly important to getting good 
code.  One could probably argue I should have kept testcases from that 
work :-)


I don't understand
> what purpose this has - if the preferred class is from the first pass, it
> is already correct, so all it does is boost the preferred class further.
> And if the preferred class is wrong (eg. after live range splitting), it
> will boost the incorrect class even harder, so in the end you never get
> a different class.
It may be historical from the old regclass code, not really sure.

>  From what you're saying, recomputing seems best, and I'd be happy to submit
> a patch to remove all the preferred class code from record_reg_classes.
Recomputing certainly helped the cases I was looking at.
> However there is still the possibility the preferred class is queried before
> the recomputation happens (I think that is a case Renlin fixed). Either these
> should be faulted and fixed by forcing recomputation, or we need to provide a
> correct preferred class. That should be a copy of the original class.
I believe I had copied the original classes, then recomputed them to 
avoid any uninitialized memory reads and the like.  But looking at the 
old branch, I don't see the recomputation for classes (though I do see 
it for costs).  Of course all the backwards walk stuff isn't there 
either, so there's clearly code I worked on extensively, but never 
committed...

Jeff