This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

cprop_reg problem on sparc

Although copy_value() in regcprop.c tries to avoid recording cases
where substitutions would be illegal, there are some bad cases it
still can let through.

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

The (set (reg:DI %g2) const_int) is generated by the *movdf_insn_sp64 insn
which in turn triggers a splitter for loading float constants into
integer registers.

The MEM:SI stores are reloads generated by IRA for a pseudo that has
to live across a call.  For whatever reason it allocated only a 4-byte
aligned stack location, and I suppose that is why the reload is split
into 2 SImode pieces.

To reproduce build gcc.c-torture/execute/ieee/mzero.c with
"-m64 -mcpu=niagara3 -O2" on sparc.

I'm suspecting that perhaps cprop is ok, and the real issue is that
sparc's definition of CANNOT_CHANGE_MODE_CLASS needs to be adjusted.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]