> Jeff Law wrote: > 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...
Well, looking into this further it does look like the preferences are improved during the 2nd pass (in particular fewer cases of the bad ALL_REGS preference that causes all the inefficient code), so it looks like recomputing preferences is not beneficial and my original patch is the right fix for now. https://gcc.gnu.org/ml/gcc-patches/2014-12/msg00829.html Wilco