Define _BitInt ABI

[jsm28]

C23 (current draft: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2912.pdf ) defines "bit-precise integer types": types _BitInt(N) and unsigned _BitInt(N) with a given width. The RISC-V ABI needs to define the ABI for these types; see the x86_64 ABI https://gitlab.com/x86-psABIs/x86-64-ABI for an example.

This means specifying the size, alignment and representation for objects of those types (including whether there are any requirements on the values of padding bits in the in-memory representation), and the interface for argument passing and return (including, again, any requirements on padding bits - both padding bits up to the size of an object of that type, and any further padding beyond that within the size of a register or stack slot used for argument passing or return).

[kito-cheng]

Thanks for remind that! we will take a look after 1.0 release!

[kito-cheng]

Notes for x86-64 ABI and current implementation status for open source toolchain:

x86-64 ABI for _BitInt:

• For N <= 64, they have the same size and alignment as the smallest of (signed and unsigned) char, short, int, long and long long types that can contain them.
• For N > 64, they are treated as struct of 64-bit integer chunks. The number of chunks is the smallest number that can contain the type. _BitInt(N) types are byte-aligned to the next greatest power-of-2 up to 64 bits. The size of these types is the smallest multiple of the 64-bit chunks greater than or equal to N. The value of the unused bits beyond the width of the _BitInt(N) value but within the size of the _BitInt(N) are unspecified when stored in memory or register.

NOTE: Added by this commit

Implementation status for open source toolchain

• clang/LLVM: Done.
• gcc: Not yet.

[cmuellner]

Some more context:

• LLVM had _ExtInt(N) before, so they could implement this feature using #define _BitInt(N) _ExtInt(N)
• The language standardization group adopted this feature under the name _BitInt(N) with N being an integral constant expression
• I could not see any patches for _BitInt(N) targeting GCC so far

Further links:

• GCC discussion: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
• LLVM documentation: https://clang.llvm.org/docs/LanguageExtensions.html#extended-integer-types
• Proposal from the ISO/IEC JTC1 SC22 WG14: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2709.pdf
• Rename patch for LLVM: https://reviews.llvm.org/D108643

[workingjubilee]

Hello,

I am raising the concern that I had with the System V x86-64 psABI specification here, in advance of this being specified at all. Namely: on a platform that has already specified __int128 with a 16-byte alignment, defining a _BitInt(N) with between 65 and 128 bits as being aligned to less than 16 bytes can have awkward results. It could significantly complicate inter-language compatibility for otherwise fairly easy-to-handle psABIs for those languages which use the system ABI (and thus the "C ABI") for parameter passing and argument return in order to translate between each other, as it creates two distinct types that nonetheless both believe they are handled as a "128-bit integer", yet have different alignments and thus different nuances, especially in stack passing.

Obviously, this concern mostly applies to the RV64-related ABIs, but to them it applies especially so, on account of the question of stack alignment. I merely took an initial reading and I am not sure I fully and correctly have calculated the cases where this will actually cause a concern for the LP64D ABI's parameter passing algorithm, so it is possible this is not a real issue for arguments, even for a very large set of function parameters. However, it still seems like it would be awkward for programmers if pointers to _BitInt(65-128) on RV64 are under-aligned for various type puns and the like.

[pinskia]

Any news on this. It would be useful to get an ABI defined soon on this and then support for _BitInt can be added to GCC.

[kito-cheng]

@pinskia thanks for the reminder, will post draft proposal soon :)