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 6293C3858C52; Fri, 28 Apr 2023 12:27:21 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6293C3858C52
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1682684841;
	bh=sdDZM/e1zuzSalSvQhyW4A6whmeYSz0FhOuVUxX2cMw=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=sbPEUr6JZx9mOAHfE9sytjja40pS+IPEtnjoi769z1hBC2jwoLOo9rrD0jrQESa1c
	 8LwQ4KxjhWoOT0FONFPlpX/qDjJWy0J+WtS7+tKPg+vHuXb5gtZZjgOb93vmNYkJx5
	 1tuGCJm9kBMWfUeDhUFrVSLLAwZmc5pe+YyudcKg=
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/109667] [12/13/14 Regression] Unnecessary
 temporary storage used for 32-byte struct
Date: Fri, 28 Apr 2023 12:27:20 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 12.3.1
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 12.3
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: target_milestone cc everconfirmed bug_status
 cf_reconfirmed_on priority
Message-ID: <bug-109667-4-iAguQ502oe@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-109667-4@http.gcc.gnu.org/bugzilla/>
References: <bug-109667-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=3D109667

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |12.3
                 CC|                            |jamborm at gcc dot gnu.org
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2023-04-28
           Priority|P3                          |P2

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.  We end up with

void assign (struct i256 * v, long int z)
{
  struct i256 r;

  <bb 2> [local count: 536870913]:
  MEM <char[24]> [(struct i256 *)&r + 8B] =3D {};
  r.v[0] =3D z_8(D);
  *v_5(D) =3D r;
  r =3D{v} {CLOBBER(eol)};
  return;
}

and I think the issue is that DSE trims the zero-initialization.  -fno-tree=
-dse
fixes it - not doing DSE enables SRA:

  r =3D {};
  r.v[0] =3D z_8(D);
  *v_5(D) =3D r;
  r =3D{v} {CLOBBER(eol)};

can SRA while

  MEM <char[24]> [(struct i256 *)&r + 8B] =3D {};
  r.v[0] =3D z_8(D);
  *v_5(D) =3D r;
  r =3D{v} {CLOBBER(eol)};

FAILs:

Candidate (2756): r
Created a replacement for r offset: 0, size: 64: r$v$0D.2766
...
  MEM <char[24]> [(struct i256 *)&r + 8B] =3D {};
  r$v$0_13 =3D z_8(D);
  r.v[0] =3D r$v$0_13;
  *v_5(D) =3D r;

that was pointless - compared to

Candidate (2756): r
Will attempt to totally scalarize r (UID: 2756):
Created a replacement for r offset: 0, size: 64: r$v$0D.2766
Created a replacement for r offset: 64, size: 64: r$v$1D.2767
Created a replacement for r offset: 128, size: 64: r$v$2D.2768
Created a replacement for r offset: 192, size: 64: r$v$3D.2769
...
  r$v$0_13 =3D 0;
  r$v$1_2 =3D 0;
  r$v$2_1 =3D 0;
  r$v$3_11 =3D 0;
  r$v$0_10 =3D z_8(D);
  v_5(D)->v[0] =3D r$v$0_10;
  v_5(D)->v[1] =3D r$v$1_2;
  v_5(D)->v[2] =3D r$v$2_1;
  v_5(D)->v[3] =3D r$v$3_11;

possibly SRA is confused by the char[24] type.  It's going to be difficult
to do better though.=