Figure out which target features are required for which SIMD size

[RalfJung]

The context for this is #116558: passing vector types by-value over extern "C" needs certain registers to be present, so if the target feature enabling these registers is missing, then either the ABI needs to change (which can lead to soundness issues if caller and callee disagree on their target features), or LLVM just errors outright.

#127731 moves us towards detecting this situation, but that approach needs data about which target feature is needed to pass which vector size. That will be different for each architecture. So this issue is about gathering all that data.

• x86 (32bit and 64bit)
  • "sse" => vlen(128)
  • "avx" => vlen(256)
  • "avx512f", "evex512" => vlen(512)
  • "amx-tile" => ??? ( matrix type, needs investigation, see Tracking Issue for x86_amx_intrinsics #126622 )
• arm
  • "neon" | "mve" => vlen(128)
• aarch64:
  • "neon" => vlen(128)
  • "sve" => "it's complicated"
• powerpc
  • "altivec" => vlen(128)
  • "mma" => vlen(512), NOTE: not supported by clang
• riscv
  • "zve32x" | "zve32f" => vlen(32),
  • "zve64x" | "zve64f" | "zve64d" => vlen(64),
  • "zvl128b" | "v" => vlen(128)
  • "zvl{N}b" => "it's complicated"
• wasm: "simd128" => vlen(128)
• loongarch: should have an on-stack ABI
• s390x: "vector" => vlen(128)
• sparc: "vis" => vlen(64) (or more? hard to say)
• hexagon
  • "hvx-length64b" => vlen(512)
  • "hvx-length128b" => vlen(1024)
• mips and mips*r6: "msa" => vlen(128)
• nvptx: vlen(128)
• bpf: none
• csky: "vdspv1" | "vdspv2" => vlen(128),
• m68k
• more?

[workingjubilee]

cc @programmerjake to confirm what features are relevant re: PowerPC

[workingjubilee]

• arm: may be able to rip something out of Revise arm platform notes regarding soft float #130987
• csky: cc @Dirreke re: target-features that affect vector ABIs?
• loongarch: cc @heiher re: target-features that affect vector ABIs?
• riscv: cc @kito-cheng or @topperc to confirm for LLVM features that can affect the vector ABI?
• s390x: this got a nice nice writeup recently in s390x vector facilities support #130869 (comment)

[programmerjake]

+altivec enables 128-bit vectors, I'm not sure if there are any wider types -- there's MMA with 512-bit accumulators, but idk if they are vector types, they're used for matrix ops.

[topperc]

riscv: cc @kito-cheng or @topperc to confirm for LLVM features that can affect the vector ABI?

+zve32x, +zve32f, +zve64x, +zve64f, +zve64d, +v, +zvbb, +zvkb. There several others that start with +zv*. There is an implies relationship so they all ultimately imply +zve32x. These change the ABI for fixed length vector arguments/returns in IR in the backend.

When compiling with clang with the default C ABI, fixed length vectors are passed coerced to a scalar integer type or passed indirectly through memory. clang will not create fixed length vector return types or arguments in IR.

There is a fixed length vector ABI being implemented via an attribute llvm/llvm-project#100346. This changes how fixed length vectors are passed.

[programmerjake]

vsx just enables an additional 32 registers that overlap with the scalar floating point registers but are otherwise the same as the 32 128-bit registers from vmx (aka. altivec), so no new simd bitwidths.

[workingjubilee]

@programmerjake and no alterations to the calling convention?