This is the mail archive of the
mailing list for the GCC project.
Re: cprop_reg problem on sparc
From: Eric Botcazou <email@example.com>
Date: Thu, 27 Oct 2011 15:17:40 +0200
>> On 64-bit sparc, integer regs are 64-bit and float regs are
>> (basically) 32-bit. So HARD_REGNO_NREGS(float_reg, DFmode) is 2, and
>> HARD_REGNO_NREGS(integer_reg, DImode) is 1.
>> cprop sees the sequence:
>> (insn 330 172 230 .. (set (reg:DI %g2) const_int)
>> (insn 171 330 173 .. (set (reg:DF %f10) (reg:DF %g2)))
>> (insn 173 171 222 .. (set (reg:DF %f2) (reg:DF %f10)))
>> (insn 222 173 223 .. (set (MEM:SI ..) (reg:SI %f10)))
>> (insn 223 222 174 .. (set (MEM:SI ..) (reg:SI %f11)))
>> And then it believes that in insn 222 it can replace %f10 with %g2,
>> but this is not a correct transformation.
>> cprop uses hard_regno_nregs to attempt to detect illegal cases
>> like this one, but such checks will not trigger here because
>> hard_regno_nregs is '1' for all of the registers being inspected:
>> hard_regno_nregs (reg:SI f10) 1
>> hard_regno_nregs (reg:DI g2) 1
> There seems to be a hole in the checks, as the number of registers is 2 for
> some of the intermediate steps.
I think cprop_reg can legitimately only consider the candidate read
replacement (reg:SI %f10) with the most recent store to it's
equivalent value (reg:DI %g2).
In fact, that's exactly what cprop_reg's core algorithm is :-)
The issue is how to test properly that accesses to a value in two
register accesses is equivalent after a move. This pass is currently
using hard_regno_nregs and a paradoxical subreg test to achieve
that, but it's obviously not sufficient.
Note that it would actually be legal to make the transformation on
insn 223, replacing %f11 with %g2.
But I'll note that if IRA had properly spilled %f10 to the stack using
an 8-byte aligned stack slot and DFmode, we wouldn't even be having to
consider this situation.
I think cprop_reg should cope with this properly, but I also think that
it would be nice if we worked to minimize unnecessary mode changes like
those seen here. The const-->DFmode splitter in sparc.md is partly to
blame, as is IRA.