RE: [PATCH] Fix IRA register preferencing

["Wilco Dijkstra" <wdijkstr@arm.com>]

> Jeff Law wrote:
> On 12/09/14 12:21, Wilco Dijkstra wrote:
> > With the fix it uses a floating point register as expected. Given a similar issue in
> > https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02253.html, would it not be better to change
> the
> > initialization values of reg_pref to illegal register classes so this kind of issue can be
> trivially
> > found with an assert? Also would it not be a good idea to have a single register copy
> function that
> > ensures all data is copied?
> But there are other times when you really don't want to copy, say when
> the original had a small class, but the copy can go into a larger class.
> 
> I banged my head on this when I was doing similar work on range
> splitting a few years back and ended up recomputing the preferred and
> alternate class information.  That was much better than copying the
> classes.

If recomputing is best does that mean that record_reg_classes should not
give a boost to the preferred class in the 2nd pass? 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.

> I pondered heuristics to expand the preferred class, but never
> implemented anything IIRC.  A trivial heuristic would be to bump to the
> next larger class if the given class was a singleton, otherwise copy the
> class.
> 
> The obvious counter to that heuristic is an allocno that has two ranges
> (or N ranges) where we would prefer a different singleton class for each
> range.  In fact, I'm pretty sure I ran into this kind of situation and
> that led me down the "just recompute it" path.
> 
> I'd hazard a guess that the simple heuristic would do better than what
> we're doing now with GENERAL_REGS though or what you're doing with copying.

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.

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.

Wilco