[Bug target/102252] svbool_t with SVE can generate invalid assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102252 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Andrew Pinski --- Fixed.
[Bug target/102252] svbool_t with SVE can generate invalid assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102252 --- Comment #6 from Gilles Gouaillardet --- I am happy to confirm this issue is fixed in the latest 12-20210919 snapshot :-) FWIW, I was not yet able to build GROMACS because of an other issue that was introduced last week. I reported it at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102421
[Bug target/102252] svbool_t with SVE can generate invalid assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102252
--- Comment #5 from CVS Commits ---
The master branch has been updated by Kyrylo Tkachov :
https://gcc.gnu.org/g:512b383534785f9fc021e700a1fdda86cf0f3fe7
commit r12-3490-g512b383534785f9fc021e700a1fdda86cf0f3fe7
Author: Kyrylo Tkachov
Date: Mon Sep 13 15:40:28 2021 +0100
aarch64: PR target/102252 Invalid addressing mode for SVE load predicate
In the testcase we generate invalid assembly for an SVE load predicate
instruction.
The RTL for the insn is:
(insn 9 8 10 (set (reg:VNx16BI 68 p0)
(mem:VNx16BI (plus:DI (mult:DI (reg:DI 1 x1 [93])
(const_int 8 [0x8]))
(reg/f:DI 0 x0 [92])) [2 work_3(D)->array[offset_4(D)]+0 S8
A16]))
That addressing mode is not valid for the instruction [1] as it only
accepts the addressing mode:
[{, #, MUL VL}]
This patch rejects the register index form for SVE predicate modes.
Bootstrapped and tested on aarch64-none-linux-gnu.
[1]
https://developer.arm.com/documentation/ddi0602/2021-06/SVE-Instructions/LDR--predicate---Load-predicate-register-
gcc/ChangeLog:
PR target/102252
* config/aarch64/aarch64.c (aarch64_classify_address): Don't allow
register index for SVE predicate modes.
gcc/testsuite/ChangeLog:
PR target/102252
* g++.target/aarch64/sve/pr102252.C: New test.
[Bug target/102252] svbool_t with SVE can generate invalid assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102252 ktkachov at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ktkachov at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from ktkachov at gcc dot gnu.org --- Testing a patch
[Bug target/102252] svbool_t with SVE can generate invalid assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102252
--- Comment #3 from ktkachov at gcc dot gnu.org ---
The RTL for the offending insn:
(insn 9 8 10 (set (reg:VNx16BI 68 p0)
(mem:VNx16BI (plus:DI (mult:DI (reg:DI 1 x1 [93])
(const_int 8 [0x8]))
(reg/f:DI 0 x0 [92])) [2 work_3(D)->array[offset_4(D)]+0 S8
A16])) "asm.c":29:29 4465 {*aarch64_sve_movvnx16bi}
(nil))
That addressing mode isn't valid for predicate loads.
In aarch64.c:aarch64_classify_address if we set allow_reg_index_p to false when
vec_flags & VEC_SVE_PRED that fixes it, but will need more testing
[Bug target/102252] svbool_t with SVE can generate invalid assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102252 ktkachov at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2021-09-09 Status|UNCONFIRMED |NEW CC||ktkachov at gcc dot gnu.org Target||aarch64 Ever confirmed|0 |1 --- Comment #2 from ktkachov at gcc dot gnu.org --- Confirmed.
[Bug target/102252] svbool_t with SVE can generate invalid assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102252 --- Comment #1 from Gilles Gouaillardet --- Created attachment 51430 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51430=edit a test that works FWIW, the attached test_svfloat.cpp passes. It is very similar to test_svbool.cpp but it "abstracts" a svfloat32_t instead of a svbool_t.
