From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id B09C4385773B; Tue, 16 May 2023 16:20:36 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B09C4385773B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1684254036; bh=c3yyCqcvWWTyRD9t1iCQhUFYvfeeJCR0UQv6O3wqOCc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=yfP+ikLzNCFczEHY7wLFKjh5xXJ+JaLE76qLnSsVEK10HvywNstfGHXClVlHEnGTY jqAxK433YLXBhmMODldmhO3T9HUj6GTesUuKuI61wULfrKvBdp+U8aSFedmiuXeqce /WzndYGqJaTHcWiFBYOd6V5xk91DtTm7YdRxVMW0= From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/102989] Implement C2x's n2763 (_BitInt) Date: Tue, 16 May 2023 16:20:34 +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.isobsolete 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 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #55056|0 |1 is obsolete| | --- Comment #40 from Jakub Jelinek --- Created attachment 55094 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D55094&action=3Dedit 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 ha= ve optional arbitrary length indirect payload, what INTEGER_CST can handle (ri= ght 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.=