From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 8A12E3858414; Wed, 24 May 2023 13:16:40 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8A12E3858414 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1684934200; bh=s1G7+N7Q4lfM75jcIZiIITGmz12SJw7t4WxwS0YivGQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ryfIPCfK7r2OlskoiZ7cslpXc+M4k+jTSPPhXz2qKGsxuIjFo2wvca8Rv/NJA1zij N+RS0svmgu4jsfW0sYl9Ct4iXIZa0gIAQlq2Z6cgAYJJ9u0EV1oOU1sdN6ciaXj4zN RenA4YTgTpWomuWVh6RsealTCnJZn2jAnTkqSy+M= From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/102989] Implement C2x's n2763 (_BitInt) Date: Wed, 24 May 2023 13:16:39 +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: 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 #45 from Jakub Jelinek --- Let's consider some simple testcase (where one doesn't really mix different _BitInt sizes etc.). _BitInt(512) foo (_BitInt(512) a, _BitInt(512) b, _BitInt(512) c, _BitInt(512) d) { return (a + b) - (c + d); } With the patch, this now ICEs during expansion, because while we can handle copying of even the larger _BitInt vars, we don't handle (nor plan to) +/- = etc. during expansion for that, it would be in the earlier lowering pass. If I'd emit straight line code here, I suppose I could use BIT_FIELD_REFs/BIT_INSERT_EXPRs, but if I want loopy code, as you wrote per= haps ARRAY_REF on VCE could work fine for the input operands, but dunno what to = use for the result of the operation, forcing it into a VAR_DECL I'm afraid will mean we can't coalesce it much, the above would force the 2 + results and 1 - result into VAR_DECLs. Could we e.g. allow BIT_INSERT_EXPRs or have some new ref for this purpose = to update a single limb in a BITTYPE_INT SSA_NAME? Now, looking what we do right now, detailed expand dump before emergency du= mp shows: Partition map Partition 0 (_1 - 1 ) Partition 1 (_2 - 2 ) Partition 2 (_3 - 3 ) Partition 3 (a_4(D) - 4 ) Partition 4 (b_5(D) - 5 ) Partition 5 (c_6(D) - 6 ) Partition 6 (d_7(D) - 7 ) which I believe means it didn't actually coalesce anything at all. For the larger BITINT_TYPEs it will be very much desirable to coalesce as much as possible, given that none of the default def SSA_NAMEs are really use I'd t= hink ideally we'd do a +=3D b c +=3D d result =3D a - c For at least multiplication/division and I assume conversions to/from float= ing point (and decimal), we'll need some library calls. One question is what ABI to use for them, whether to e.g. pass pointer to t= he limbs (and when -fbuilding-libgcc predefine macros on what mode is the limb mode, whether the limbs are ordered from least significant to most or vice versa, etc.) and in addition to that precision in bits for each argument and wheth= er it is zero or sign extended from that, so that we could e.g. handle more efficiently _BitInt(16384) foo (unsigned _BitInt(2048) a, _BitInt(1024) b) { return (_BitInt(16384) a) * b; } by passing e.g. _mulwhatever (&res, 16384, &a, 2048, &b, -1024) where -1024 would mean 1024 bits sign extended, 2048 2048 bits zero extende= d, result is 16384 bits. And for GIMPLE a question is how to express it before expansion, whether we use some ifn that is then lowered.=