[cfe-dev] {u}int_fastN_t Types and Preprocessor Defines

[Sam Elliott via cfe-dev]

Hi cfe-dev!

I am currently investigating an ABI incompatibility for RISC-V between Clang and GCC.

GCC defines `{u}int_fast8_t` and `{u}int_fast16_t` to be the same sizes as `{u}int32_t` or `{u}int64_t`, depending on the underlying hardware register length (RISC-V has a 32-bit architecture and a 64-bit architecture). This, to me, makes sense, as there are no sub-registers in the architecture. The `{u}int_least8_t` and `{u}int_least16_t` match their bitwidths.

However, in Clang, I believe we cannot have `{u}int_fastN_t` different from the equivalent `{u}int_leastN_t`, as the codebase currently stands, due to both `DefineFastIntType` and the definitions in `clang/lib/Headers/stdint.h`.

Point one is while investigating this, Luis discovered that on x86 these types *do* differ in size: https://godbolt.org/z/rrNGPa
I cannot work out how x86 manages this, because my reading of stdint.h and the clang codebase do not show any codepaths where this would work. Any help to shed light on how this is done would be useful.

Point two is that I have started a patch to add a `getFastIntTypeByWidth` hook for Clang, which by default defers to `getLeastIntTypeByWidth`, to match the current behaviour. The comment in `DefineFastIntType` points to me having to update `stdint.h` to ensure these match, and any guidance about doing so would be appreciated. The patch is here: https://reviews.llvm.org/D80963 

I know psABIs are a minefield (to say nothing of preprocessors ;) ), so I'm keen to see if we can add this functionality for RISC-V without breaking any other architectures. psABIs are hard enough to verify at the best of times.

Thanks In Advance,

Sam

--
Sam Elliott
Software Team Lead
Senior Software Developer - LLVM and OpenTitan
lowRISC CIC