This change enables the use of RISCV's variable length vector registers for fixed length vectors in the IR, and implicitly enables various IR transforms which generate fixed length vectors if legal (e.g. LoopVectorize and SLPVectorize). Specifically, this enables fixed length vectors which are known to be inbounds of the underlying variable hardware size.
For context, remember that the +V extension provides a minimum VLEN of 128. The embedded variants provide lower minimums. The analogy here is essentially vectorizing for SSE on a machine which may or may not include AVX2/AVX512. We won't get full utilization by default, but we will get some benefit. And of course, with an explicit mcpu we can vectorize to the exact target hardware.
The LV impact is mostly related to vectorizer robustness. In cases we haven't yet fully implemented scalable vectorization support, we can fall back to fixed length vectorization. Note that there a bunch of cases we haven't yet implemented, so in practice this is a fairly major shift towards auto-vectorizing more often.
On the SLP side, I haven't done anywhere near as detailed an evaluation, but the initial investigation I did do ran into a few open issues. Given that, I've posted a change which disables SLP even when fixed vectors are enabled, and marked it as dependency for this one.
This case demonstrates an unfortunate, but I think non-blocking interaction. Essentially, with vectors illegal, we force scalarization and then constant fold the individual scalar lanes. With vectors legal, we fail to recognize that scalarization is profitable, or that lane 0 is unused. As a result, we fail to constant fold. This is a general problem with vector codegen optimization, and not directly related to this change.