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 AMX target features and 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?