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. 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.