[llvm] [RISCV][GlobalISel] Legalize G_ADD, G_SUB, G_AND, G_OR, G_XOR on RISC-V Vector Extension (PR #71400)

[Craig Topper via llvm-commits]

topperc wrote:

> I have a question when I'm writing the test cases with the `-mattr=+zve32x` flag.
> 
> @topperc mentioned that `<vscale x 1 x s8>`, `<vscale x 1 x s16>`, `<vscale x 1 x s32>` require `ST.getELen() == 64`.
> 
> Can you point me to the source documentation file that states this requirement? I'm looking at [this register info chart](https://github.com/llvm/llvm-project/blob/75d6795e420274346b14aca8b6bd49bfe6030eeb/llvm/lib/Target/RISCV/RISCVRegisterInfo.td#L268) and I'm wondering, since `nxv1i8` can be intepreted as `MF8` under `ELEN`=64, why can't we make it as `MF4` under `ELEN=32` as well?

Currently `vscale` is defined as VLENB/8 or VLEN/64 this limits some parts of our implementation to VLEN >= 64. For ELEN=32 we should define vscale as VLENB/4 or VLEN/32 and use a different type mapping where nxv1i8 would map to MF4 and nxv4i8 would map to M1. This would allow us to support VLEN=32. This would require twice as many isel patterns in RISCVGenDAGISel.inc which is already a very large table so we haven't done it.

We currently have partial support for VLEN=32 using intrinsics as long as llvm.vscale is not used and no spills/reloads of vectors occur.

SelectionDAG currently widens nxv1i8 to nxv2i8 and uses a MF4 arithmetic instructions without initializing the extra elements. Loads/stores of nxv1i8 will calculate a VL instead of using VLMAX in order to avoid accessing more memory than nxv1i8 should.

https://github.com/llvm/llvm-project/pull/71400