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]
