From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id C52343857357; Wed, 17 May 2023 07:22:03 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C52343857357
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1684308123;
	bh=2WkccSaPLZlz8TcQ+i4HcU7nUhPdNyGE/TCvimpD+XY=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=je52XT/4uROSnNEEGnEKaaOe++zQewyXCeDexSvM9nE8iFKKCjNMGWQ1NbPnb2SNx
	 niiaJhMWXp4+8gjGmvRoI+VTpL9D964a2yEBDENqfEJo7yWe7VZM3m30dHa4EzoqZ0
	 BC0rq37gLpTbrcx3r/trBTk8hX1k27gkmAHLNQxI=
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/102989] Implement C2x's n2763 (_BitInt)
Date: Wed, 17 May 2023 07:22:02 +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: rguenth 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: 
Message-ID: <bug-102989-4-7LQmImLgUS@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-102989-4@http.gcc.gnu.org/bugzilla/>
References: <bug-102989-4@http.gcc.gnu.org/bugzilla/>
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: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102989

--- Comment #41 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #40)
> Created attachment 55094 [details]
> gcc14-bitint-wip.patch
>=20
> 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 gr=
ow
> it
> further is a question).
>=20
> 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 pa=
ss
> which will turn the larger ones into loops etc.).  Also, wb/uwb constants
> aren't
> really done yet.

Another idea is to have a large BITINT_MAXWIDTH (up to what TYPE_PRECISION
supports) but restrict constant folding to the cases we can represent in
INTEGER_CST.  For the cases where the language requires constant evaluation
we'd then sorry ().  I think we should be able to handle all-ones
encoded and since constant initializers are restricted it should handle
most practical cases already.=