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

[Robin Dapp <rdapp.gcc@gmail.com>]

Hi,

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.

So while I was still commenting on the other V1 patch I realized
that V2 is already in now :)

>     return TYPE_ALIGN (TREE_TYPE (type));

I'm not sure this is what we want or rather what the hardware wants.
The preferred alignment of a VNx4SI (or larger) is 32 bit/4 bytes
then - even 1 byte for a QI vector?
Of course, we don't peel for alignment then anymore but we
might actually want to, depending on the hardware.

I mean as a temporary workaround it might be acceptable but do we
actually need to get rid of the peeling code?  If the hardware
supports unaligned access without penalty we should specify in
the vectorization costs

e.g.
      case unaligned_load:
      case unaligned_store:
	return 1;

(Your "return 1" for riscv_builtin_vectorization_cost will do
that as well of course).

and the peeling cost check should do the rest (i.e. nothing :) ).

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.

Regards
 Robin