Standard Fixed-length Vector Calling Convention Variant #418
Conversation
| @@ -329,6 +329,81 @@ type would be passed. | |||
| Floating-point registers fs0-fs11 shall be preserved across procedure calls, | |||
| provided they hold values no more than ABI_FLEN bits wide. | |||
|
|
|||
| === Standard Fixed-length Vector Calling Convention Variant | |||
There was a problem hiding this comment.
The variant itself seems fine, modulo nits, but how are we planning to enable it?
If it's automatically used by -march=rva23 -mabi=ilp32d that will create major compatibility issues for binary distributions that use a fixed ABI and allow mixing packages at different architecture levels (either as an explicit user action, or as an implementation detail when rebuilding the distribution to change the architecture requirement).
If a new -mabi= value is required to enable use of the variant, it will be usable on closed systems where all packages are built at once, but not on binary distributions, since there is no expectation that binary code built with different -mabi= options is interoperable at all. This will include Debian and Alpine and might include Android and Fedora if their ABIs are finalized prior to the acceptance of this PR.
If it's enabled on a per-function basis using an attribute, or automatically for functions not visible across DSO boundaries, then it's effectively part of the definition of the attribute or a compiler implementation detail and may belong in riscv-c-api-doc or gccint, not here.
There was a problem hiding this comment.
My expectation is that should be enabled by per-function basis by attribute, and I think that should have a riscv-c-api-doc PR for that, will send that in the next few days.
kito-cheng
force-pushed
the
fixed-length-vector-cc
branch
from
b9f0bc2
to
2386a73
Compare
|
ChangeLog:
|
|
ChangeLog:
|
…n variant Fixed-length vector are passed via general purposed register or memory within current ABI design, we proposed a standard fixed-length vector calling convention variant for passing the fixed-length vector via vector register. This is the syntax part in the proposal, further detail for that calling convention variant see riscv-non-isa/riscv-elf-psabi-doc#418
|
Proposal for function attribute syntax: riscv-non-isa/riscv-c-api-doc#68 |
|
|
||
| A struct containing just one fixed-length vector array is passed as though it | ||
| were a vector tuple type if the size of the base element for the array is less | ||
| or equal to 8×ABI_VLEN bit, and the size of the array is less than 8×ABI_VLEN |
There was a problem hiding this comment.
| or equal to 8×ABI_VLEN bit, and the size of the array is less than 8×ABI_VLEN | |
| or equal to 4×ABI_VLEN bit, and the size of the array is less than or equal to 8×ABI_VLEN |
There was a problem hiding this comment.
Since the array would have >=2 elements here, so I think the length can't be 8xABI_VLEN.
There was a problem hiding this comment.
Array with length 1 is legal :P
riscv-cc.adoc
Outdated
| cores with longer VLEN. | ||
|
|
||
| A fixed-length vector argument is passed in a vector argument register if the | ||
| size of the vector is less than ABI_VLEN bit. |
There was a problem hiding this comment.
Should this be "no more than ABI_VLEN bits"?
This proposal outlines a new variant of the calling convention specifically designed for fixed-length vectors. The primary aim of this variant is to facilitate the passing of fixed-length vectors through vector registers. This approach is derived from the standard vector calling convention, it uses the same register conventions and argument passing and return value rules. A key aspect of this variant is the introduction of ABI_VLEN, which denotes the width of a vector register within this convention. The ABI_VLEN is constrained to be no wider than the ISA's VLEN (Vector Length), ensuring compatibility while allowing for flexibility in different implementations. This parameter can be configured via compiler command line options or through function attributes in source code. The document recommends setting the default ABI_VLEN to 128 bits, acknowledging it as a common minimal requirement while allowing the flexibility for lower VLEN (32 or 64 bits) as permitted by the ISA. This flexibility is crucial for optimizing the utilization of longer VLENs in various cores. The proposal specifies how fixed-length vector arguments are passed based on their size relative to ABI_VLEN. Vectors smaller than ABI_VLEN are passed in a single vector argument register, while larger vectors are passed in multiple registers, following the LMUL (Length Multiplier) pattern of 2, 4, or 8, depending on their size. Additionally, the proposal addresses the handling of structs and unions containing fixed-length vectors. Structs with members that are all fixed-length vectors follow the vector tuple type rules if they conform to size constraints. In contrast, unions with fixed-length vectors adhere to the integer calling convention.
- Reorder rule. - Pass struct as tuple-type in register only when vector arg reg is enough, otherwise passed in reference. - Add NOTE for describe what if ABI_VLEN is smaller than VLEN, also come with an example. - Add NOTE for describe different functions may use different ABI_VLEN values.
- Add rule for single fixed-length vector or fixed-length vector array with size 1. - Add rule for zero-length fixed-length arrays. - Add explicitly rule for fixed-length vector struct as vector tuple type: pass by ref if no enough arg register.
Co-authored-by: Brandon Wu <[email protected]> Signed-off-by: Kito Cheng <[email protected]>
kito-cheng
force-pushed
the
fixed-length-vector-cc
branch
from
c84ebb1
to
7e9d68c
Compare
Signed-off-by: Kito Cheng <[email protected]>
This proposal outlines a new variant of the calling convention specifically designed for fixed-length vectors. The primary aim of this variant is to facilitate the passing of fixed-length vectors through vector registers. This approach is derived from the standard vector calling convention, it uses the same register conventions and argument passing and return value rules.
A key aspect of this variant is the introduction of ABI_VLEN, which denotes the width of a vector register within this convention. The ABI_VLEN is constrained to be no wider than the ISA's VLEN (Vector Length), ensuring compatibility while allowing for flexibility in different implementations. This parameter can be configured via compiler command line options or through function attributes in source code.
The document recommends setting the default ABI_VLEN to 128 bits, acknowledging it as a common minimal requirement while allowing the flexibility for lower VLEN (32 or 64 bits) as permitted by the ISA. This flexibility is crucial for optimizing the utilization of longer VLENs in various cores.
The proposal specifies how fixed-length vector arguments are passed based on their size relative to ABI_VLEN. Vectors smaller than ABI_VLEN are passed in a single vector argument register, while larger vectors are passed in multiple registers, following the LMUL (Length Multiplier) pattern of 2, 4, or 8, depending on their size.
Additionally, the proposal addresses the handling of structs and unions containing fixed-length vectors. Structs with members that are all fixed-length vectors follow the vector tuple type rules if they conform to size constraints. In contrast, unions with fixed-length vectors adhere to the integer calling convention.