Hi Kito,
> GNU vector extensions is widly used around this world, and this patch
> enable that with RISC-V vector extensions, this can help people
> leverage existing code base with RVV, and also can write vector programs in a
> familiar way.
>
> The idea of VLS code gen support is emulate VLS operation by VLA operation
> with
> specific length.
>
> Key design point is we defer the mode conversion (From VLS to VLA mode) after
> register allocation, it come with several advantages:
> - VLS pattern is much friendly for most optimization pass like combine.
> - Register allocator can spill/restore exact size of VLS type instead of
> whole register.
>
> This is compatible with VLA vectorization.
>
> Only support move and binary part of operation patterns.
On a high-level: Why do we need to do it this way and not any other way? :)
Some more comments/explanations would definitely help, i.e. prior art on
aarch64, what exactly is easier for combine and friends now (no undef and so
on) and, importantly, why is the conversion after register allocation always
safe? Couldn't we "lower" the fixed-length vectors to VLA at some point and
how does everything relate to fixed-vlmax? Essentially this is a "separate"
backend similar to ARM NEON but we share most of the things and possibly grow
it in the future?
What would the alternative be?
That said, couldn't we reuse the existing binop tests? If you don't like them
change the existing ones as well and reuse then?
> +/* Return the minimal containable VLA mode for MODE. */
> +
> +machine_mode
> +minimal_vla_mode (machine_mode mode)
> +{
> + gcc_assert (GET_MODE_NUNITS (mode).is_constant ());
> + unsigned type_size = GET_MODE_NUNITS (mode).to_constant ();
Couldn't you use .require () right away? Same in some other hunks.
Regards
Robin
