From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 1CD493856DE6; Fri, 2 Jun 2023 17:06:33 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1CD493856DE6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1685725594; bh=ZNwbfiqhM4eBRIg2imSks7TLPLKSF73Jn3TBTqgtVJY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=eYA2FMSQDpI79eA9tg64s+J9aERLUiwACZCW9sWR7O7wsrMvkxPPXYee5SG4PzDz0 3k8dvChbm2dEgilF498o7zIGDjI7pomAGvzaHPJlrMdL+oVulvBBxaYUu1mJUZ4Se6 ZUYTArJhb2VVWyQcvwcYMrB1o0kZjBDqzhFcUHgo= From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/102989] Implement C2x's n2763 (_BitInt) Date: Fri, 02 Jun 2023 17:06:32 +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 #56 from Jakub Jelinek --- Created attachment 55244 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D55244&action=3Dedit gcc14-bitint-wip-inc.patch Incremental patch on top of the above patch. I've tried to make some progress and implement the simplest large _BitInt cases, &/|/^/~, but ran into a problem there, both BIT_FIELD_REF and BIT_INSERT_EX= PR disallow operating on non-mode precisions, while for _BitInt I think it would be rea= lly useful to use them on the large/huge _BitInts (which I will force into memory duri= ng expansion most likely). Sure, for huge _BitInts, what is handled in the lo= op 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. 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? Another thing, started to think about PLUS_EXPR/MINUS_EXPR, we have __builtin_ia32_addcarryx_u64/__builtin_ia32_sbb_u64 builtins on x86-64, but from what I can see don't really pattern recognize even simple add + adc. Given: void foo (unsigned long *p, unsigned long *q, unsigned long *r) { unsigned long p0 =3D p[0], q0 =3D q[0]; unsigned long p1 =3D p[1], q1 =3D q[1]; unsigned long r0 =3D p0 + q0; unsigned long r1 =3D p1 + q1 + (r0 < p0); r[0] =3D r0; r[1] =3D r1; } void bar (unsigned long *p, unsigned long *q, unsigned long *r) { unsigned long p0 =3D p[0], q0 =3D q[0]; unsigned long p1 =3D p[1], q1 =3D q[1]; unsigned long p2 =3D p[2], q2 =3D q[2]; unsigned long r0 =3D p0 + q0; unsigned long r1 =3D p1 + q1 + (r0 < p0); unsigned long r2 =3D p2 + q2 + (r1 < p1 || r1 < q1); r[0] =3D r0; r[1] =3D r1; r[2] =3D r2; } llvm seems to pattern recognize foo, but doesn't pattern recognize bar as a= dd; adc; adc (is that actually a correct C for that though?). So, shouldn't we implement the clang's https://clang.llvm.org/docs/LanguageExtensions.html#multiprecision-arithmet= ic-builtins builtins (add least the __builtin_{add,sub}c{,l,ll} builtins), lower them i= nto ifns early (similarly to .{ADD,SUB}_OVERFLOW returning complex integer with= 2 returns) and add optabs so that targets can implement those efficiently?=