Re: cprop_reg problem on sparc

[David Miller <davem@davemloft.net>]

From: Eric Botcazou <ebotcazou@adacore.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.