https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #55056|0 |1
is obsolete| |
--- Comment #40 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 55094
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55094&action=edit
gcc14-bitint-wip.patch
So, on IRC we've agreed with Richi that given the limits we have in the
compiler
(what wide_int/widest_int can represent at most without making the types have
optional arbitrary length indirect payload, what INTEGER_CST can handle (right
now 255 64-bit limbs) and TYPE_PRECISION limitation (max 65535 precision))
it would be best to first try to implement _BitInt support with small
BITINT_MAXWIDTH (in particular, what fits into wide_int, which is e.g. on
x86_64
575 bits) and only when the implementation of that is complete, attempt to lift
up some of the limits (start with the wide_int/widest_int one, INTEGER_CST
could
be handled by bumping the 2 counters from 8-bit to 16-bit and killing the
cache,
with that we'd be at 65535 as BITINT_MAXWIDTH and whether we'd want to grow it
further is a question).
This patch implements some WIP, as the testcases show, it can already do
something, but doesn't have any of the argument/return value passing code
implemented, nor middle-end needed changes (promoting as much as possible to
small INTEGER_TYPEs early for small BITINT_TYPEs and adding a lowering pass
which will turn the larger ones into loops etc.). Also, wb/uwb constants
aren't
really done yet.
