https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120811
Jeffrey A. Law <law at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed| |2025-06-27
--- Comment #3 from Jeffrey A. Law <law at gcc dot gnu.org> ---
Thanks for the reduction. As I suspected it's an artifact of
adddi3_const_sum_of_two_s12, though not in the precise way I expected.
As we enter the register allocator we have:
(insn 300 217 303 11 (set (reg:DI 478 [ MEM[(long int *)&ap + 1624B] ])
(mem:DI (plus:DI (reg/f:DI 65 frame)
(const_int 1616 [0x650])) [2 MEM[(long int *)&ap + 1624B]+0 S8
A64])) 277 {*movdi_64bit}
(nil))
We do fp->sp elimination resulting in an out of range constant so we reload
into:
(insn 512 487 300 12 (set (reg:DI 6 t1 [657])
(plus:DI (reg/f:DI 2 sp)
(const_int 2048 [0x800]))) 7 {*adddi3_const_sum_of_two_s12}
(nil))
(insn 300 512 488 12 (set (reg:DI 6 t1 [orig:478 MEM[(long int *)&ap + 1624B] ]
[478])
(mem:DI (reg:DI 6 t1 [657]) [2 MEM[(long int *)&ap + 1624B]+0 S8 A64]))
277 {*movdi_64bit}
(nil))
Then we have to split insn 512 because that's not a real instruction resulting
in:
(insn 521 487 522 12 (set (reg:DI 6 t1 [657])
(plus:DI (reg/f:DI 2 sp)
(const_int 2047 [0x7ff]))) 5 {adddi3}
(nil))
(insn 522 521 300 12 (set (reg:DI 6 t1 [657])
(plus:DI (reg:DI 6 t1 [657])
(const_int 1 [0x1]))) 5 {adddi3}
(nil))
(insn 300 522 488 12 (set (reg:DI 6 t1 [orig:478 MEM[(long int *)&ap + 1624B] ]
[478])
(mem:DI (reg:DI 6 t1 [657]) [2 MEM[(long int *)&ap + 1624B]+0 S8 A64]))
277 {*movdi_64bit}
(nil))
So much later in the optimizer pipeline. We used to have a hook that allowed
the target to guide reloading that was particularly useful for these scenarios.
It was used extensively on the PA1.1 architecture which only had a 5 bit
encoding for displacement in FP loads/stores. With some rewriting of the
reloads we'd be able to share a base pointer calculation across several reloads
which differed in that 5 bit offset.
The point is I think we need to be looking at the code generation for reloads
in LRA. The big question I'd want to answer is whether or not we use the
adddi/addsi expanders when we generate an address reload in LRA. If we do,
then I think Shreya's work may be the answer. If not, I think there's a couple
of other places in LRA where we can influence how address reloads are handled.
