https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
--- Comment #36 from Jakub Jelinek <jakub at gcc dot gnu.org> --- Created attachment 55056 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55056&action=edit gcc14-bitint-wip.patch Just WIP on the top of the above patch, which does parsing of the _BitInt type specifier in C and introduces BITINT_TYPE (I'm afraid we can't use INTEGER_TYPE for that, both because it can have different calling/returning convention in different ABIs and because we need more than 16-bit precision for it as well), but still doesn't use it (right where it would create it stops for now and pretends it is integer). I've added also wb/WB suffix parsing on the libcpp side, but that is where I stopped today. Obviously for CPP_N_BITINT we need different interpretation of the number because cpp_interpret_integer can handle at most 128-bit integers (and of course even for the integers that fit into 128-bit with wb/WB suffixes we also want to use the right type; but I guess we can use INTEGER_CSTs for them). I'm afraid we'll need some other TREE_CODE for bit-precise integer constants which don't fit into widest_int (perhaps better for all that don't fit into 128 bits), because the amount of code that assumes wi::to_widest works on INTEGER_CSTs is huge. As I said earlier, I think something during gimplification or soon after it could remap small _BitInts (up to 128-bit resp. 64-bit when TImode isn't supported) to normal integral types except on the function boundaries (where ABI conventions can result in different rules for them), but probably we can't make INTEGER_TYPE <-> BITINT_TYPE conversions useless because _BitInt could be e.g. passed to varargs. Looking at what clang does, they seem to have raised the limit from 128 to 8388608, but in many cases they emit extremely terrible code. Everything is done without library support inline and even for huge numbers it doesn't even use any loops, so is extremely cache unfriendly. I think we should do something like that solely for very small cases, otherwise use loops and either let normal unrolling do its job, or say do 4 limbs in the loop body at a time or something similar. And would be nice if the ranger could at least discover ranges of how many real bits each SSA_NAME can contain (with bits above those being zero or sign extended) so that we could use more efficient additions/subtractions/multiplications/divisions etc.
