[Bug target/55212] [SH] Switch from IRA to LRA

[kkojima at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #53 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #52)
> Created attachment 33632 [details]
> Reduced case of error: in assign_by_spills, at lra-assigns.c:1335 with -m4
> -ml -O2

.ira dump of the test case has the lines

(insn 145 144 148 8 (set (reg/v:SI 245 [ qval ])
        (mem:SI (plus:SI (reg/v/f:SI 345 [orig:213 divisors ] [213])
                (reg:SI 349 [orig:259 ivtmp.27 ] [259])) [7 MEM[base:
divisors_17, index: ivtmp.27_119, offset: 0B]+0 S4 A32])) jcdctmgr.i:87 258
{movsi_ie}
     (nil))
(insn 148 145 149 8 (set (reg/v:SI 246 [ temp ])
        (mem:SI (plus:SI (reg:SI 349 [orig:259 ivtmp.27 ] [259])
                (reg:SI 334)) [7 MEM[symbol: workspace, index: ivtmp.27_119,
offset: 0B]+0 S4 A32])) jcdctmgr.i:88 258 {movsi_ie}
     (nil))

which correspond to the lines

 qval = divisors[i];
 temp = workspace[i];

of the test case.  r349 is the index variable i and r334 is the pointer
variable workspace.  LRA assigns R0_REGS to r349 at insn 145 because
rtlanal.c:decompose_mem_address guesses r345 would be base and r349 index.
Unfortunately, that function also guesses r349 would be base and r334 index
at insn 148.  LRA tries to assign R0_REGS to r334 according to this "guess"
result.  .reload dump says:

Changing address in insn 148 r349:SI+r334:SI on equiv r349:SI+sfp:SI
      Creating newreg=384 from oldreg=153, assigning class R0_REGS to address
r384
      Creating newreg=385 from oldreg=349, assigning class R0_REGS to address
r385

Thus regclass of r384 and r385 corrides at insn

  148: r246:SI=[r385:SI+r384:SI]