For the RVV backend, I see two options:

1. rvv-vls: We specialize multiple full backends for a specific vector lengths (templated) and select the apropriate one based on the native vector length. This will work best with the current abstractions, but inflates binary size and only works for 128/256/512-bit vectors, because masks are stored in uint64_t, which reduces possible ILP.

2. rvv-vla: We write a fully custom vector length agnostic backend, not using the generic backend (...scanner abstractions). This would only instantiate a single new backend and expose more ILP (e.g. we can choose higher LMUL when apropriate), because we don't assume a specific vector length.

I would be more interested in writing (2), but that will take some time.
Doing (1) is easier and, apart from the templating, a 1-to-1 port of the existing backends.

I think it's best to do both, then we can compare which is faster and, if (1) is faster, we can still use (2) as a fallback for longer vectors.

You can't put dynamic code intostatic_assert, there also is no need to.abstract the reading of vlenb.
There should also be no need to check for padding as RVV can be presicated based on vl. (There is no need to align to the vector length eitger, I'd choose some default like aligne to 64 bytes, when we can choose a buffer alignment)

You can't put dynamic code intostatic_assert, there also is no need to.abstract the reading of vlenb. There should also be no need to check for padding as RVV can be presicated based on vl. (There is no need to align to the vector length eitger, I'd choose some default like aligne to 64 bytes, when we can choose a buffer alignment)

@camel-cdr
You're absolutely right — I made some basic mistakes and the CI failures proved it. I'll fix them. Thanks for pointing them out.

This fails to build, because you can't put RVV types into structs, since they are sizeless-types.
The best way to do this currently is using theriscv_rvv_vector_bits attribute and the-mrvv-vector-bits=128 compiler flag.
This will however only work for VLEN that doesn't match the specified-mrvv-vector-bits and AFAIK you can't have fixed width RVV types for different VLEN in the same translation unit.

Ideally the fixed width backend would be compiled for-mrvv-vector-bits=128,-mrvv-vector-bits=256 and-mrvv-vector-bits=512 separately.

You should really compile and run the code locally before sending a PR.