From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 044C53857734; Thu, 11 May 2023 18:21:51 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 044C53857734 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1683829312; bh=f5M+Sd1xe9rhUXrWl8hDIr9CyggauiFNDBSCaunwuO4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=g0Va/s9k5x8Bg7dn/iH9C80VhdLLpYxMWyK4wN3ZeNrSszWyab4ya9X7xnI7AF9LB Id9h46Q3fzs72WFobNn9rqO/db1wdCOjzmd53CVulFUGlfJrD2rYsRDgB4PETXaBEy pMeT7kZLffbjG0lpiojk5LsMP4vhiimkUQNtuNeY= From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/102989] Implement C2x's n2763 (_BitInt) Date: Thu, 11 May 2023 18:21:51 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: 12.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102989 --- Comment #36 from Jakub Jelinek --- Created attachment 55056 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D55056&action=3Dedit gcc14-bitint-wip.patch Just WIP on the top of the above patch, which does parsing of the _BitInt t= ype 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 wel= l), 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 suffi= xes 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 w= orks 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 r= esp. 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 ev= en 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 ei= ther let normal unrolling do its job, or say do 4 limbs in the loop body at a ti= me or something similar. And would be nice if the ranger could at least disco= ver ranges of how many real bits each SSA_NAME can contain (with bits above tho= se being zero or sign extended) so that we could use more efficient additions/subtractions/multiplications/divisions etc.=