https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123092
--- Comment #7 from Vineet Gupta <vineetg at gcc dot gnu.org> ---
Gave Andrew's test a spin
With IRA things seem ok:
There's an address computation and the prefetch
```
(insn 6 9 12 2 (set (reg/f:DI 139 [ d.b ])
(mem/f/c:DI (lo_sum:DI (reg/f:DI 137)
(symbol_ref:DI ("d") [flags 0x86] <var_decl 0x703ee5bc5be0 d>)) [1 d.b+0 S8
A64])) {*movdi_64bit}
(expr_list:REG_EQUIV (mem/f/c:DI (lo_sum:DI (reg/f:DI 137)
(symbol_ref:DI ("d") [flags 0x86] <var_decl 0x703ee5bc5be0 d>)) [1
d.b+0 S8 A64])
(expr_list:REG_EQUAL (mem/f/c:DI (symbol_ref:DI ("d") [flags 0x86] <var_decl
0x703ee5bc5be0 d>) [1 d.b+0 S8 A64])
(nil))))
(insn 8 12 13 2 (prefetch (plus:DI (reg/f:DI 139 [ d.b ])
(const_int 64 [0x40]))
(const_int 0 [0])
(const_int 3 [0x3])) {prefetch}
(expr_list:REG_DEAD (reg/f:DI 139 [ d.b ])
(nil)))
```
LRA then decided to fold the addr computation into prefetch itself
```
Removing equiv init insn 6 (freq=1000)
6: r139:DI=[r137:DI+low(`d')]
REG_EQUIV [r137:DI+low(`d')]
REG_EQUAL [`d']
deleting insn with uid = 6.
Considering alt=0 of insn 12: (0) =r (1) r
Choosing alt 0 in insn 8: (0) Qr (1) i (2) n {prefetch}
(insn 8 12 13 2 (prefetch (plus:DI (mem/f/c:DI (lo_sum:DI (reg/f:DI 10 a0
[137])
(symbol_ref:DI ("d") [flags 0x86] <var_decl 0x703ee5bc5be0
d>)) [1 d.b+0 S8 A64])
(const_int 64 [0x40]))
(const_int 0 [0])
(const_int 3 [0x3])) {prefetch}
(nil))
```
Which is what eventually ICE in final pass.
I initially thought this was a regression from my prev patch in the area with
relaxing the constraint to "Qr" to allow reloads, but removing the "r"
experimentally doesn't fix this.
The preetch pattern as defined allows PLUS but then requires operand0 to be a
register, but it seems LRA is not honoring that for some reason.
Haven't looked into why LRA is doing this.
