[clang] [compiler-rt] [ubsan] Display correct runtime messages for negative _BitInt (PR #96240)

[Jakub Jelínek via llvm-commits]

================
@@ -103,6 +103,13 @@ class TypeDescriptor {
     /// representation is that of bitcasting the floating-point value to an
     /// integer type.
     TK_Float = 0x0001,
+    /// An _BitInt(N) type. Lowest bit is 1 for a signed value, 0 for an
+    /// unsigned value. Remaining bits are log_2(bit_width). The value
----------------
jakubjelinek wrote:

bit_width of what?  The main problem is that the _BitInt ABI is only defined in the x86-64 and aarch64 psABIs, for i686 the word was that the ABI should be whatever GCC implemented, but nobody updated the ia32 psABI yet.
I think ARM 32-bit is defined too, some other targets are working on it.
As documented in LLVM, it implements _BitInt everywhere but notes that the ABI can change (GCC took a different approach, only implementing it for arches which agree on an ABI).
So, if compiler-rt implements _BitInt support, it better be able to encode the various ABIs which will be used for _BitInt on various arches.
The current ABIs usually have some special cases for smaller number of bits, but those generally can be encoded as normal integer (sign or zero extended say to long long or __int128).
For the large _BitInts, x86_64 uses little endian ordered array of 64-bit limbs, aarch64 little or big endian ordered array of 128-bit limbs, ia32 little endian ordered array of 32-bit limbs.
But I was told the powerpc folks are considering little endian ordering of limbs on both ppc64le and ppc64 big-endian.
So, I think you certainly want to encode the limb size and the N from _BitInt(N) and whether it is signed or unsigned and possibly (e.g. for ppc64) also whether the limbs are ordered from least significant to most or vice versa (bit ordering within limb would be normally dependent on endianity).
So, I think that bit_width in the bits above sign should be the limb size, not _BitInt size rounded up or whatever you're implementing right now.  And encode somewhere the endianity too.

https://github.com/llvm/llvm-project/pull/96240