https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118669
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords|internal-improvement |wrong-code
Summary|Misaligned store after |Misaligned store after
|after vectorization without |vectorization without using
|using misaligned type with |misaligned type with SVE
|SVE |
CC| |rsandifo at gcc dot gnu.org,
| |tnfchris at gcc dot gnu.org
Component|tree-optimization |target
Target| |aarch64
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
If you dump GIMPLE with -gimple you see the alignment used.
__MEM <int [[gnu::vector_size([16,16])]]> ((int *)vectp_a.7_40) =
vect_vec_iv_.6_37;
vectp_a.7_43 = vectp_a.7_40 + POLY_INT_CST [16ul, 16ul];
__MEM <int [[gnu::vector_size([16,16])]]> ((int *)vectp_a.7_43) = _39;
indeed since no alignment is specified, it's natural alignment. The SVE
loop is correct:
.MASK_STORE (vectp_a.12_59, _Literal (int *) 32, _61, vect_vec_iv_.11_54);
t.c:4:21: note: === vect_analyze_data_refs_alignment ===
t.c:4:21: note: recording new base alignment for a_8(D)
alignment: 4
misalignment: 0
based on: *_3 = j_13;
t.c:4:21: note: vect_compute_data_ref_alignment:
t.c:4:21: missed: misalign = 0 bytes of ref *_3
so it seems the target says '4' is "aligned" rather than using
dr_unalign_supported?
This looks like a target issue to me.
