https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116033
Christoph Müllner <cmuellner at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Last reconfirmed| |2024-07-24
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |cmuellner at gcc dot
gnu.org
--- Comment #1 from Christoph Müllner <cmuellner at gcc dot gnu.org> ---
I've prepared a patch that disables pre-/post-modify addressing if RVV is
enabled:
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/658119.html
The underlying issue is outlined in the commit message.
We are confronted with the following optimization from auto_inc_dec (-O3),
when RVV and XTheadMemIdx are enabled:
```
(insn 23 20 27 3 (set (mem:V4QI (reg:DI 136 [ ivtmp.13 ]) [0 MEM <vector(4)
char> [(char *)_39]+0 S4 A32])
(reg:V4QI 168)) "gcc/testsuite/gcc.target/riscv/pr116033.c":12:27
3183 {*movv4qi}
(nil))
(insn 40 39 41 3 (set (reg:DI 136 [ ivtmp.13 ])
(plus:DI (reg:DI 136 [ ivtmp.13 ])
(const_int 20 [0x14]))) 5 {adddi3}
(nil))
====>
(insn 23 20 27 3 (set (mem:V4QI (post_modify:DI (reg:DI 136 [ ivtmp.13 ])
(plus:DI (reg:DI 136 [ ivtmp.13 ])
(const_int 20 [0x14]))) [0 MEM <vector(4) char> [(char
*)_39]+0 S4 A32])
(reg:V4QI 168)) "gcc/testsuite/gcc.target/riscv/pr116033.c":12:27
3183 {*movv4qi}
(expr_list:REG_INC (reg:DI 136 [ ivtmp.13 ])
(nil)))
```
One solution would be to introduce a target hook to check if a certain
type can be used for pre-/post-modify optimizations.
However, it will be hard to justify such a hook if only a single
RISC-V vendor extension requires that.
Therefore, this patch takes a more drastic approach and disables
pre-/post-modify addressing if TARGET_VECTOR is set.
This results in not emitting pre-/post-modify instructions from
XTheadMemIdx if RVV is enabled.
