No, ARM SVE is 128bit alignment instead of element align (in aarch64-modes.def).
If you want to tune the alignment, you should add tunning info into riscv-modes.def instead of this target hook. Thanks. juzhe.zh...@rivai.ai From: Robin Dapp Date: 2023-05-15 16:58 To: juzhe.zh...@rivai.ai; Kito.cheng; richard.sandiford CC: rdapp.gcc; gcc-patches; palmer; jeffreyalaw Subject: Re: [PATCH] RISC-V: Support TARGET_VECTORIZE_PREFERRED_VECTOR_ALIGNMENT to optimize codegen of RVV auto-vectorization > After this patch, RVV GCC by default support alignment of RVV modes > according to riscv-modes.def. In riscv-modes.def, we define each RVV > modes are element align which is aligned to RVV ISA spec. > > If you want to support other alignment, you should add tunning info > for this in the future. And the default behavior in case of alignment > which is already in this patch should not be changed in the future. We're changing the preferred_vector_alignment hook, not the vector_alignment hook. The way I see it, we will never peel for alignment when setting the preferred_alignment to the alignment of a single element, no matter the cost of misaligned loads/stores. Is the idea then to adjust the preferred_alignment hook depending on mtune? IMHO it's much more "natural" to set the vectorization costs according to mtune (done anyway at some point), not change the preferred_alignment and let the vectorizer decide whether is has enough information on whether to peel or not. Maybe Richard can comment here on why the vector_alignment_preferred hook was originally introduced or what wasn't possible without it (i.e. why not go via costs). At some point the vectorizer would peel even if the costs were low for misaligned accesses but that had already been fixed before the hook was introduced. And ABI-wise (and that's what the V spec documents) we are already safe by using MIN (128, TYPE_SIZE (type)). We could probably even lower that? Regards Robin
