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 63E563858CDB; Wed, 24 May 2023 13:29:59 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 63E563858CDB
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1684934999;
	bh=zVS8d76EAYlCOZbePkP57/i5ZLb1gnaLMGNZcM39D4s=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=ci9ucz2NupCI76nPB0EQf5Ax6f94STCawCKkeb6j2p3L6MY3YsqIF6JEKh8Iznmsn
	 OXX3+l4AKdJOtqCA1/uj5Ei603PlU9kaXJ2t6JKfuySY17H9yges1G4UqMv6QYb9l6
	 lxatsvFaG93bopu6yvL8WpNKL/GGX68AC4L0hu3g=
From: "rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/102989] Implement C2x's n2763 (_BitInt)
Date: Wed, 24 May 2023 13:29:58 +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: rguenther at suse dot de
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-Shqnx4u7h6@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 #46 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 24 May 2023, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102989
>=20
> --- Comment #45 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> Let's consider some simple testcase (where one doesn't really mix differe=
nt
> _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 hand=
le
> 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 p=
erhaps
> ARRAY_REF on VCE could work fine for the input operands, but dunno what t=
o 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 - res=
ult
> into VAR_DECLs.
> Could we e.g. allow BIT_INSERT_EXPRs or have some new ref for this purpos=
e to
> update a single limb in a BITTYPE_INT SSA_NAME?

I think for complex expressions that involve SSA temporaries the lowering
pass has to be more complex as well and gather as much of the expression
as possible so it can avoid _BitInt typed temporaries but instead create

 for (...)
  {
    limb_t tem1 =3D a[i] + b[i];
    limb_t tem2 =3D c[i] + d[i];
    limb_t tem3 =3D tem1 - tem2;
    res[i] =3D tem3;
  }

but yes, for the result you want to force a VAR_DECL (I suppose
DECL_RESULT for the above example will be one).  I'd probably avoid
rewriting user variables into SSA form and only have temporaries
created by gimplifications in SSA form.  You should be able to use
DECL_NOT_GIMPLE_REG_P to force this and make sure update-address-taken
leaves things this way unless, say, the user variable is only
initialized by a constant?=