https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116541
Tamar Christina <tnfchris at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |wilco at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed| |2024-09-02
Status|UNCONFIRMED |NEW
--- Comment #1 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
(In reply to ktkachov from comment #0)
> I don't know if Tamar's pending IVOPTs fix this but filing it here just in
> case
No, this isn't an IVopts problem. The loop has only one IV expression, however
the way we expand the address breaks the addressing mode.
in GCC 13 we had:
(insn 19 18 20 4 (set (reg:DI 114)
(high:DI (const:DI (plus:DI (symbol_ref:DI ("c") [flags 0x82]
<var_decl 0x7f459713a000 c>)
(const_int 4 [0x4]))))) "/app/example.c":15:49 -1
(nil))
(insn 20 19 21 4 (set (reg:DI 113)
(lo_sum:DI (reg:DI 114)
(const:DI (plus:DI (symbol_ref:DI ("c") [flags 0x82] <var_decl
0x7f459713a000 c>)
(const_int 4 [0x4]))))) "/app/example.c":15:49 -1
(expr_list:REG_EQUAL (const:DI (plus:DI (symbol_ref:DI ("c") [flags 0x82]
<var_decl 0x7f459713a000 c>)
(const_int 4 [0x4])))
(nil)))
(insn 21 20 22 4 (set (reg/f:DI 112)
(plus:DI (reg:DI 100 [ ivtmp.21 ])
(reg:DI 113))) "/app/example.c":15:49 -1
(nil))
(insn 22 21 23 4 (set (reg:SF 116)
(mem:SF (reg/f:DI 112) [1 MEM[(float *)&c + 4B + ivtmp.21_32 * 1]+0 S4
A32])) "/app/example.c":15:46 -1
(nil))
and in GCC 14:
(insn 19 18 20 4 (set (reg:DI 123)
(high:DI (symbol_ref:DI ("c") [flags 0x82] <var_decl 0x71a14cf0a120
c>))) "/app/example.c":15:49 -1
(nil))
(insn 20 19 21 4 (set (reg:DI 122)
(lo_sum:DI (reg:DI 123)
(symbol_ref:DI ("c") [flags 0x82] <var_decl 0x71a14cf0a120 c>)))
"/app/example.c":15:49 -1
(expr_list:REG_EQUAL (symbol_ref:DI ("c") [flags 0x82] <var_decl
0x71a14cf0a120 c>)
(nil)))
(insn 21 20 22 4 (set (reg/f:DI 121)
(plus:DI (reg:DI 101 [ ivtmp.22 ])
(reg:DI 122))) "/app/example.c":15:49 -1
(nil))
(insn 22 21 23 4 (set (reg:SF 125)
(mem:SF (plus:DI (reg/f:DI 121)
(const_int 4 [0x4])) [1 MEM[(float *)&c + 4B + ivtmp.22_1 *
1]+0 S4 A32])) "/app/example.c":15:46 -1
(nil))
i.e. the offset is now in the memory access rather than in the address
calculation. This means that the base is updated rather than the offset, as
the offset is now a constant.
This is due to:
commit db4e496aadf1d7ab1c5af24410394d1551ddd3f0
Author: Wilco Dijkstra <wilco.dijks...@arm.com>
Date: Tue Jan 16 16:27:02 2024 +0000
AArch64: Reassociate CONST in address expressions
GCC tends to optimistically create CONST of globals with an immediate
offset.
However it is almost always better to CSE addresses of globals and add
immediate
offsets separately (the offset could be merged later in single-use cases).
Splitting CONST expressions with an index in aarch64_legitimize_address
fixes
part of PR112573.
gcc/ChangeLog:
PR target/112573
* config/aarch64/aarch64.cc (aarch64_legitimize_address):
Reassociate
badly formed CONST expressions.
gcc/testsuite/ChangeLog:
PR target/112573
* gcc.target/aarch64/pr112573.c: Add new test.
Confirmed.
