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)
• arm
  • "neon" => vlen(128)
  • "mve" => ???
• aarch64:
  • "neon" => vlen(128)
  • "sve" & -Cllvm-args="--aarch64-sve-vector-bits-min={N}" => vlen(N), NOTE: only scalable vectors?
• hexagon
  • "hvx-length64b" => vlen(512)
  • "hvx-length128b" => vlen(1024)
• powerpc
  • "altivec" => vlen(128)
  • "mma" => vlen(512), NOTE: not supported by clang
• mips: "msa" => vlen(128)
• riscv
  • "zve32x" | "zve32f" => vlen(32),
  • "zve64x" | "zve64f" | "zve64d" => vlen(64),
  • "zvl128b" | "v" => vlen(128)
  • "zvl{N}b" => vlen(N)
  • "zvl" & -Cllvm-args="--riscv-v-vector-bits-min={N}" => vlen(N), NOTE: only scalable vectors?
• wasm: "simd128" => vlen(128)
• bpf: none
• csky: "vdsp1" | "vdsp2" => vlen(128),
• loongarch: should have an on-stack ABI
• s390x: "vector" => vlen(128)
• 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?

[workingjubilee]

@topperc hm, it seems LLVM doesn't have the crypto implications for these features specified here? is it somewhere else? https://github.com/llvm/llvm-project/blob/d54953ef472bfd8d4b503aae7682aa76c49f8cc0/llvm/lib/Target/RISCV/RISCVFeatures.td#L734-L746

it seems to rather be the opposite, a requirement relationship, but perhaps I'm misunderstanding: https://github.com/llvm/llvm-project/blob/d54953ef472bfd8d4b503aae7682aa76c49f8cc0/llvm/lib/TargetParser/RISCVISAInfo.cpp#L754-L758

[topperc]

@topperc hm, it seems LLVM doesn't have the crypto implications for these features specified here? is it somewhere else? https://github.com/llvm/llvm-project/blob/d54953ef472bfd8d4b503aae7682aa76c49f8cc0/llvm/lib/Target/RISCV/RISCVFeatures.td#L734-L746

it seems to rather be the opposite, a requirement relationship, but perhaps I'm misunderstanding: https://github.com/llvm/llvm-project/blob/d54953ef472bfd8d4b503aae7682aa76c49f8cc0/llvm/lib/TargetParser/RISCVISAInfo.cpp#L754-L758

My mistake. I'm not sure why we don't have the implies. gcc does.

[programmerjake]

@programmerjake and no alterations to the calling convention?

enabling vsx doesn't alter the calling convention.

[RalfJung]

+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.

Are there types which are passed via these MMA registers?

[RalfJung]

My mistake. I'm not sure why we don't have the implies. gcc does.

For us it's nice that there's no "implies" here, that makes it a lot easier to check the ABI consequences. ;) This way we juts have to block the actual feature changing something, not other features implying them.

Though maybe this is also unnecessary if #131807 takes care of all that.

EDIT: Ah, that's just for float ABI, not for vectors, is it?

[RalfJung]

-Cllvm-args="--riscv-v-vector-bits-min=N"

Uh wait a second, we are exposing another flag that can change ABI? 😢 😭

EDIT: That's probably a discussion for Zulip.

[heiher]

LoongArch: According to the LoongArch ABI Specs, vector type parameters and return values ​​are passed in GAR(general-purpose argument registers) or on the stack, and do not rely on vector registers or vector features.

[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.

Are there types which are passed via these MMA registers?

after a bit more research, there are types for MMA, but you can't pass them by value in function arguments or return, so they're not ABI-breaking: https://clang.godbolt.org/z/e4sTY37Pv
they lower to <256 x i1> and <512 x i1>

[workingjubilee]

...concerning. these blockades are in clang's semantic checks, they don't seem to be enforced by LLVM.

[workingjubilee]

cc @jacobbramley re: aarch64

[workingjubilee]

cc @androm3da re: hexagon

[RalfJung]

after a bit more research, there are types for MMA, but you can't pass them by value in function arguments or return

How do we handle that in Rust? We'd need a special pass during collection rejecting them as arguments, likely as part of the simd arg check that this issue is about.

I assume we don't support these types yet, but this will need to be considered when someone decides to add them.

[RalfJung]

-Cllvm-args="--riscv-v-vector-bits-min=N"

Uh wait a second, we are exposing another flag that can change ABI? 😢 😭

I only just realized this only affects scalable vector types. Which anyway we don't support. So we can ignore this for now.

[Dirreke]

According to the CSKY Development Guide: 4.5 vdsp, the vector width is configured as follows:

For vdspv2, the width is fixed at 128 bits.
For vdspv1, the default width is 128 bits, but it can optionally be set to 64 bits using the -mvdsp-width=64 compiler flag. However, please note that the 64-bit width option is currently unsupported by LLVM.

Therefore, for both versions, you can safely set the vector width to 128 bits.

csky:
"vdsp1" | "vdsp2" => vlen(128),

[androm3da]

Hexagon HVX supports uses these target flags - +hvx-length64b, +hvx-length128b, +hvx, +hvxv60 through +hvxv73 (explicitly 60,62,65,66,67,68,69,71,73). hvx-length64b maps to 64 byte (512 bit) value registers, hvx-length128b is 128 byte (1024 bit) value reg. These registers can also be paired.

Oh - and there's also vector predicate registers - they're 64-bit and 128-bit wide in hvx-length64b and hvx-length-128b modes, respectively. These registers can also be quad'd.

All of these vector, vector-predicate registers are caller-saved.

Link to hexagon ABI doc