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?

[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:
"vdspv1" | "vdspv2" => vlen(128),

[taiki-e]

SPARC's Vector ABI is defined based on the existing float and aggregate calling convention, not the VIS ISA ¹, and changing it without a new ABI would also break other non-vector arguments due to the nature of using FP registers. So, I don't believe it can be changed without a new ABI. (This is very different from the x86_64, which extended the ISA in the form of increasing the size of the vector registers.)

That said, if our policy is to not trust the current behavior of psABI with respect to vectors larger than ISA supports ², I think the 64-bit mentioned in #131800 (comment) is safe selection.

Footnotes

1. sparc_pass_by_reference and sparc_return_in_memory in GCC have comments about this. ↩

2. I think this is the correct policy for most architectures. ↩

[RalfJung]

SPARC's Vector ABI is defined based on the existing float and aggregate calling convention, not the VIS ISA

So having or not having vis actually makes no difference for how things are passed?
That would mean we could actually allow arbitrary-size vectors -- once we implement the existing ABI correctly, of course.

[taiki-e]

So having or not having vis actually makes no difference for how things are passed?
That would mean we could actually allow arbitrary-size vectors -- once we implement the existing ABI correctly, of course.

Good point. Looking at the assemblies generated by GCC it does not appear to be affected by -mvis (affected by -msoft-float, though): https://godbolt.org/z/3sTMqoaq4

(As for SPARC's soft-float target feature, it should be marked as Forbidden anyway because it affects the float ABI: #131799 (comment))

[RalfJung]

Yeah, most targets have a soft-float feature and it should be forbidden on all of them. But not all do, e.g. aarch64 does not.

[workingjubilee]

OTOH vectors larger than a register are also odd. So I don't really understand what to do with this.

Fun facts to know and tell: RVV also supports these! it's something called a "register group", and is modified by LMUL ("length multiplier"), which its a bitfield that specifies a value in {8, 4, 2, 1, 1/2, 1/4, 1/8}. When LMUL is greater than 1, instructions that manipulate vectors in vector registers must address a register with an appropriate factor, but they otherwise operate like a vector of the currently-set vector length multiplied by LMUL.

[workingjubilee]

Thank you everyone for participating, I believe we have concluded this investigation for now. There are some only-partly-resolved questions so I opened new issues for them:

• How should we handle SPARC's vector ABI? #133141
• How should we handle matrix ABIs? #133144
• How should we handle dynamic vector ABIs? #133146