From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 201473856090; Mon, 5 Jun 2023 07:43:03 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 201473856090 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1685950984; bh=sXPJT1rPihMNml7NiHf1WWdMF+I86bNN1MTLVcQa+lw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=bw5gajUBG0meArgEX/LRpfh08hJyUVaynsLChWsUqEf/qJBmIR6+hV/cYthOVOknO SLXDWfpS1Ps26SazyPaTdr1Mtkh8qr3SRzHa5LMQrEZ70PztoULPE3K/CBBCl7lzkV 4N4CwljpolwYJi7V2di4XKetM5byHo8CYOxY0+iw= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/102989] Implement C2x's n2763 (_BitInt) Date: Mon, 05 Jun 2023 07:43:03 +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: 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 #59 from Richard Biener --- (In reply to Jakub Jelinek from comment #58) > (In reply to Richard Biener from comment #57) > > (In reply to Jakub Jelinek from comment #56) > > > Created attachment 55244 [details] > > > gcc14-bitint-wip-inc.patch > > >=20 > > > Incremental patch on top of the above patch. > > >=20 > > > I've tried to make some progress and implement the simplest large _Bi= tInt > > > cases, > > > &/|/^/~, but ran into a problem there, both BIT_FIELD_REF and > > > BIT_INSERT_EXPR disallow > > > operating on non-mode precisions, while for _BitInt I think it would = be > > > really useful > > > to use them on the large/huge _BitInts (which I will force into memory > > > during expansion most likely). Sure, for huge _BitInts, what is hand= led in > > > the loop will use either > > > ARRAY_REF on VIEW_CONVERT_EXPR for operands or TARGET_MEM_REFs on VAR= _DECLs > > > for the results in the loop, but even for those there is the partial = most > > > significant limb in some cases that needs to be handled separately. > > >=20 > > > So, do you think it is ok to make an exception for > > > BIT_FIELD_REF/BIT_INSERT_EXPR and > > > allow them on non-mode precision BITINT_TYPEs (the incremental patch = enables > > > that) plus > > > handle it during the expansion? > >=20 > > The incremental patch doesn't implement the expansion part, right? The >=20 > Not yet. >=20 > > problem is that BIT_* are specified to work on the in-memory representa= tion > > and a non-mode precision entity doesn't have this specified - you'd have > > to extend / shift that to some mode to be able to store it. >=20 > One thing is that the checking and expansion constraints preclude using it > even on > full limbs of a _BitInt which has precision in multiples of limb precisio= n. > Say _BitInt(192) has on x86-64 3 64-bit limbs, but the type necessarily h= as > BLKmode, > because there are no 192-bit modes. > If we allowed BIT_FIELD_REF/BIT_INSERT_EXPR on non-type_has_mode_precisio= n_p > BITINT_TYPEs, perhaps we could restrict it to the cases we really need and > which can be easily implemented. That is, they'd need to extract or inse= rt > bits within the same single limb, making it effectively operate on mode > precision of the limb for all the limbs other than the most significant > partial one if any, and in the case of the most significant one it could > either ignore the padding bits above it or sign/zero extend > into the padding bits when touching the MSB bit (depending on if target s= ays > those bits are well defined or undefined). Oh, so BITINT_TYPE is INTEGRAL_TYPE_P but not INTEGER_TYPE (I think we don't have any BLKmode integer types?). I think the intent was to restrict the operation on actual mode entities, BLKmode means memory where it isn't necessary to restrict things. So you could add a BLKmode exception here (but then for _BitInt<63> you will likely get DImode?) Can't you use a MEM_REF to extract limb-size INTEGER_TYPE from the _BitInt<> and then operate on those with BIT_FIELD_REF and BIT_INSERT_EXPR? Of course when the whole _BitInt<> is a SSA name MEM_REF won't work (but when you use ARRAY_REF/VIEW_CONVERT the same holds true) > > Improving code-gen for add-with carry would be indeed nice, I'm not sure > > we need the user-visible builtins though, matching the open-coded varia= nts > > to appropriate IFNs would work. But can the _OVERFLOW variants not be > > used here, at least for unsigned? >=20 > Yeah, just noticed the clang builtins are badly designed, see PR79173 for > that, > so will try to introduce a new ifns and pattern detect them somewhere.=