Re: Re: [PATCH] RISC-V: Support TARGET_VECTORIZE_PREFERRED_VECTOR_ALIGNMENT to optimize codegen of RVV auto-vectorization

["juzhe.zhong@rivai.ai" <juzhe.zhong@rivai.ai>]

[-- Attachment #1: Type: text/plain, Size: 2024 bytes --]

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.zhong@rivai.ai
 
From: Robin Dapp
Date: 2023-05-15 16:58
To: juzhe.zhong@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