[Bug c/102989] Implement C2x's n2763 (_BitInt)

["jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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.