https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97875
Christophe Lyon changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97875
--- Comment #7 from CVS Commits ---
The master branch has been updated by Christophe Lyon :
https://gcc.gnu.org/g:25bef68902f42f414f99626cefb2d3df81de7dc8
commit r11-6616-g25bef68902f42f414f99626cefb2d3df81de7dc8
Author: Christophe Lyon
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97875
Christophe Lyon changed:
What|Removed |Added
Status|WAITING |ASSIGNED
--- Comment #6 from Christoph
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97875
--- Comment #5 from Christophe Lyon ---
Interestingly, if I make arm_builtin_support_vector_misalignment() behave the
same for MVE and Neon, the generated code (with __restrict__) becomes:
test_vsub_i32:
@ args = 0, pretend = 0, frame = 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97875
--- Comment #4 from Christophe Lyon ---
In both cases (Neon and MVE), DR_TARGET_ALIGNMENT is 8, so the decision to emit
a useless loop tail comes from elsewhere.
And yes, MVE vldrw.32 and vstrw.32 share the same alignment properties.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97875
Richard Biener changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97875
--- Comment #2 from Christophe Lyon ---
Checking the Arm v8-M manual, my understanding is that this architecture does
not support unaligned vector loads/stores.
However, my understanding is that vldrw.32 accepts to load from addresses
aligned on
