| Issue |
60925
|
| Summary |
Concerns about x86-64 `_BitInt(65-128)` alignment
|
| Labels |
new issue
|
| Assignees |
|
| Reporter |
workingjubilee
|
It is my understanding that currently, for the System V AMD64 ABI specification of `_BitInt(65-128)`, it has an alignment of only 8, whereas `__int128` has an alignment of 16. If I remember correctly, since both are specified to be "as if a struct of 8bytes", this has no consequence for the raw by-value case for functions with a few parameters. However, in the presence of many arguments, this means that it will hit the stack, and that it will be passed differently than `__int128` on the stack. It also means that if an allocation attempts to align itself to `_BitInt(128)`, it is incorrectly aligned for `__int128`, whereas `__int128` is correctly (over)aligned for `_BitInt(128)` allocations.
I have a concern about cross-language, and even, to some extent, assembly-code interoperability. A lack of 16-byte alignment means the type is incorrectly aligned using as a target of CMPXCHG16B's all-important m128 operand which _must_ be 16-byte aligned (an indicator of a 128-bit value at a memory address, not to be confused with `__m128`, which only prefers it for VEX encodings, except for VMOVAPS, but also the legacy SSE encodings still exist). It also means that any other programming language must double-up on types in order to do C FFI for such 16-byte types, whereas in some cases they may already have such types (and may want to already be able to use it for `__int128`). Obviously, the C Standard doesn't guarantee other languages won't need them anyways, but it still seems preferable if more implementations choose the form which has the largest aligned integer type match `_BitInt(N)`, even if merely for principle-of-least-astonishment reasons, and to help other compiler implementers down the road.
Obviously, we still need a stopping point somewhere. I only suggest it here as it's already a specified large integer type. The stack is 16-byte-aligned anyways, too.
I am aware that this decision is ultimately also something that requires the attention of the people who specified the psABI, and I have [raised this as an issue with them](https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/11). I am mentioning it to you, here, because I wish to make sure this concern is factored in to the release of LLVM 16, and because Clang is the pioneer of this implementation.
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
