[PATCH] Fix IRA register preferencing

[Jeff Law]

On 12/09/14 12:21, Wilco Dijkstra wrote:
> This fixes a bug in register preferencing. When live range splitting creates a new register from
> another, it copies most fields except for the register preferences. The preference GENERAL_REGS is
> used as reg_pref[i].prefclass is initialized with GENERAL_REGS in allocate_reg_info () and
> resize_reg_info ().
>
> This initialization value is not innocuous like the comment suggests - if a new register has a
> non-integer mode, it is forced to prefer GENERAL_REGS. This changes the register costs in pass 2 so
> that they are incorrect. As a result the liverange is either spilled or allocated to an integer
> register:
>
> void g(double);
> void f(double x)
> {
>    if (x == 0)
>      return;
>    g (x);
>    g (x);
> }
>
> f:
>          fcmp    d0, #0.0
>          bne     .L6
>          ret
> .L6:
>          stp     x19, x30, [sp, -16]!
>          fmov    x19, d0
>          bl      g
>          fmov    d0, x19
>          ldp     x19, x30, [sp], 16
>          b       g
>
> 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.

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.

jeff