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: 1856 bytes --]

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.

Thanks.


juzhe.zhong@rivai.ai
 
From: Kito Cheng
Date: 2023-05-15 16:02
To: Robin Dapp
CC: juzhe.zhong@rivai.ai; gcc-patches; palmer; jeffreyalaw
Subject: Re: [PATCH] RISC-V: Support TARGET_VECTORIZE_PREFERRED_VECTOR_ALIGNMENT to optimize codegen of RVV auto-vectorization
> we need to discern what we want to achieve here.  The goal might
> be to prevent the vectorizer from performing peeling or versioning
> for alignment.  I realize the peeling code looks ugly but it's
> actually for a good cause when the target does not support
> misaligned vector access or only with severe penalty.
 
Vector spec says it should support element alignment, so my
understanding is default behavior should be just aligned to
vector-spec said :)
 
I guess Ju-Zhe might have different thoughts on that, we might need
some more comment from him.
 
 
> So I'd much rather prefer that over the current approach as it
> is more localized and will need an mtune-related approach later
> anyway.
 
I know there is some HW implementation that might be faster if the
address is aligned to 128 bit or 256 bit, and some HW implementation
might only get a few penalties from the first iteration if not aligned
to some alignment.
 
Anyway those are all mtune-related, so I guess eventually both
riscv_builtin_vectorization_cost and
riscv_vectorize_preferred_vector_alignment should get info from mtune.
 
 
>
> Regards
>  Robin