How should we handle SPARC's vector ABI?

[workingjubilee]

This concerns SPARC and its vis AKA Visual Instruction Set. Quoting from @taiki-e

AFAIK it's at least 64-bit.

• GCC's SPARC VIS builtins provides vector_size (8) (64-bit) and vector_size (4) (32-bit) vectors.
• According to calling conventions implemented by GCC:
• On SPARC32: 64-bit or smaller vector integer is passed using int reg (argument) / FP reg (return value)
• On SPARC64: 128-bit(argument)/256-bit(return value) or smaller vector integer/float are passed using FP reg

SPARC FP registers (f[0-63]) are 32-bit long, and two/four of these are combined to process f64/f128. 64-bit VIS vectors also use two FP registers, as does f64.

128-bit/258-bit vectors are also passed or returned using four/eight FP registers.
https://github.com/gcc-mirror/gcc/blob/730f28b081bea4a749f9b82902446731ec8faa93/gcc/config/sparc/sparc.cc#L7388

In any case, LLVM doesn't currently support Vector ABI (llvm/llvm-project#45418), so it seems that using vlen(0) in the lint is correct for now.

SPARC's Vector ABI is defined based on the existing float and aggregate calling convention, not the VIS ISA [^1], 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.)

See also:

• ABI checks: add support for tier2 arches #132842 (comment)
• Figure out which target features are required for which SIMD size #131800 (comment)

[workingjubilee]

Thanks to @taiki-e's description it seems we understand as much as there is to understand and all that is left here is mostly integrating that information and making decisions, perhaps after consulting any SPARC ISA experts working on LLVM.