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
