_BitInt implementation does not conform to x86-64 psABI regarding padding bits

[leni536]

clang version: 16.0.0
compiler flags: -std=c2x -O2

Observed behavior

Given the following code:

unsigned char f(unsigned _BitInt(4)* ptr) {
    return *ptr;
}

unsigned char g(_BitInt(4)* ptr) {
    unsigned _BitInt(4) uint = *ptr;
    return uint;
}

The generated code for f and g does not mask out "unused" bits from *ptr:

f:                                      # @f
        movzx   eax, byte ptr [rdi]
        ret
g:                                      # @g
        movzx   eax, byte ptr [rdi]
        ret

https://godbolt.org/z/Ev8sbhb84

Expected behavior

The x86-64 psABI specifies that the unused bits within an object of _BitInt(N) type can take unspecified values:

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.

https://gitlab.com/x86-psABIs/x86-64-ABI/-/blob/3177443c4f5862d48f371d91ab36209f73cfe69c/x86-64-ABI/low-level-sys-info.tex#L297-299

This means that *ptr in both cases can have the object representation 0b00010000, representing the signed/unsigned _BitInt(N) value 0. But according to the generated code this object representation is passed as-is to the returned unsigned char in both cases, which translates to the return value 16.

As 0b00010000 is a valid object representation for representing the value 0 here, I would expect both functions to return 0 in this case.

In general this requires masking out the unused bits.

Notes

It looks like the current implementation assumes that valid object representations have all zeroes for the unused bits, and other representations are trap representations.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

[llvmbot]

@llvm/issue-subscribers-backend-x86

[royjacobson]

This looks to me like a backend bug. The IR we output is (https://godbolt.org/z/3bTnhaqbf):

define dso_local zeroext i8 @f(ptr nocapture noundef readonly %0) local_unnamed_addr #0 {
  %2 = load i4, ptr %0, align 1, !tbaa !6
  %3 = zext i4 %2 to i8
  ret i8 %3
}

and apparently the zext i4 %2 to i8 is optimized out?

[royjacobson]

relevant - https://discourse.llvm.org/t/why-do-sub-byte-loads-on-aarch64-not-require-masking/68309

[royjacobson]

cc @AaronBallman - If I understand correctly the discourse thread above, the psABI _BigInt might be currently unimplementable in LLVM?

[AaronBallman]

Errrrr, I hope that's not the case, but it sure looks like LLVM is doing unexpected things by removing that zext (I think that might be an LLVM bug -- we're expecting non-multiples-of-8-bit integer types to Just Work from the frontend perspective.)

[AaronBallman]

CC @FreddyLeaf @phoebewang as they know far, far more about the x86 backend than I do.

[nikic]

Yes, it looks like psABI is incompatible with LangRef:

When loading a value of a type like i20 with a size that is not an integral number of bytes, the result is undefined if the value was not originally written using a store of the same type.

When writing a value of a type like i20 with a size that is not an integral number of bytes, it is unspecified what happens to the extra bits that do not belong to the type, but they will typically be overwritten.

Non-byte-sized types in LLVM do not have a specified ABI, just that loads and stores have consistent semantics. In practice, those semantics are to zero-extend values to the byte-sized type (but with caveats due to store elision).

We would need to either change LangRef and backend lowerings, or make the frontend lower non-byte-sized BitInt stores to the next byte-sized width, the same as is done for _Bool.