[Vector ABI] Type size and alignment for vector types. #380
Conversation
There was a problem hiding this comment.
Thanks @kito-cheng for this.
The issue of Vector alignment is discussed in #347. It is mentioned that aligning to 128 bytes might deliver better performance on some RISC-V cores,
I think you meant 128 bits? (later on you say 96 bits which would match with bits).
Just to confirm the intent of this change: this is always minimal alignment and a compiler implementation/platform may choose to use a larger value. Also, a user could use __attribute__((aligned(16))) (or similar mechanisms) to enforce larger alignments.
Now this probably only impacts stack variables but if we ever have aggregates of vector type, the alignment will be used there when computing offsets. Maybe I'm missing some other case.
Yeah, should be
Yes, compiler always has freedom to use bigger/higher alignment, and this mostly affect stack object, another one that will be affected is |
I understand LLVM mask type size is adjusted as doc said. However, GCC byte size of these mask type is not adjusted like this. GCC configuration for BOOL type I am not sure whether this inconsistency between GCC and LLVM is necessary to be documented in the ABI doc. Otherwise, LGTM. Thanks. |
Yeah, I know GCC has did some more compact way, that's the reason I add the note at the end:
Thanks for review :) |
|
Changes:
|
|
The motivation of updating the vector mask type to more compact size: this allow compiler to store that in compact way without ABI violation. |
|
Changes:
|
|
Changes:
|
The issue of Vector alignment is discussed in #347. It is mentioned that aligning to 128 bytes might deliver better performance on some RISC-V cores, but this behavior could lead to considerable stack wastage on zve32 and zve64 cores. For instance, in order to ensure a vector value in the stack conforms to the ABI specification, we could potentially waste up to 96 bits per vector object in stack for zve32, and the performance difference isn't always evident across all core implementations. Therefore, this proposal sets the alignment of vector types to element alignment, to avoid wasting a significant amount of stack space in zve32 and zve64 configurations. Also, since the ABI only specify the minimum alignment and doesn't limit the compiler from adopting higher alignment for specific CPUs. Fix #347.
kito-cheng
force-pushed
the
vector-align
branch
from
c97faa1
to
6b3f877
Compare
|
Going to merge this, thanks everyone :) |
The issue of Vector alignment is discussed in #347. It is mentioned that aligning to 128 bits might deliver better performance on some RISC-V cores, but this behavior could lead to considerable stack wastage on zve32 and zve64 cores. For instance, in order to ensure a vector value in the stack conforms to the ABI specification, we could potentially waste up to 96 bits per vector object in stack for zve32, and the performance difference isn't always evident across all core implementations.
Therefore, this proposal sets the alignment of vector types to element alignment, to avoid wasting a significant amount of stack space in zve32 and zve64 configurations. Also, since the ABI only specify the minimum alignment and doesn't limit the compiler from adopting higher alignment for specific CPUs.
Fix #347.