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]

Re: cprop_reg problem on sparc

> 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.

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

AFAICS there is no such file as gcc.c-torture/execute/ieee/mzero.c.

> 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.

I'm a little skeptical at this point.

Eric Botcazou

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