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 81EBA3858D20; Tue, 30 May 2023 16:45:02 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 81EBA3858D20
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1685465102;
	bh=iHqyJ2GyBjrl4u5kOsF5P2NvGEiP/NvRECOtH/ewnFw=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=OuulrSIt78GvkSt4MA+FXJLR3d4QH8Kd8klOlCGbKrQZ8bWVEes4691TaoKJXl8gE
	 Cr57ejq/RuuauamjyRZ6qM4F1bY2OqR5a36thuzbhN/MTtgIjMdH/ISgDQAUxZFijd
	 wCKwweWypZUEYC2xVbcG0ZiuUpDamt0V6vwHT47Y=
From: "pinskia at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/110035] Missed optimization for dependent
 assignment statements
Date: Tue, 30 May 2023 16:45:02 +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.1.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: pinskia 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: keywords everconfirmed bug_severity
 cf_reconfirmed_on bug_status
Message-ID: <bug-110035-4-1fhCLKsvj2@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-110035-4@http.gcc.gnu.org/bugzilla/>
References: <bug-110035-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=3D110035

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization
     Ever confirmed|0                           |1
           Severity|normal                      |enhancement
   Last reconfirmed|                            |2023-05-30
             Status|UNCONFIRMED                 |NEW

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
In the case of x86_64, it is just moving the loads across the operator new,=
 I
think:
  vect_SR.14_5 =3D MEM <vector(2) long unsigned int> [(struct MyClass
&)obj_2(D)];
  vect_SR.15_28 =3D MEM <vector(2) long unsigned int> [(struct MyClass &)ob=
j_2(D)
+ 16];
  vect_SR.16_30 =3D MEM <vector(2) long unsigned int> [(struct MyClass &)ob=
j_2(D)
+ 32];
  _6 =3D operator new (48);
  MEM <vector(2) long unsigned int> [(struct MyClass2 *)_6] =3D vect_SR.14_=
5;
  MEM <vector(2) long unsigned int> [(struct MyClass2 *)_6 + 16B] =3D
vect_SR.15_28;
  MEM <vector(2) long unsigned int> [(struct MyClass2 *)_6 + 32B] =3D
vect_SR.16_30;
  HandleMyClass2 (_6); [tail call]

Other targets is moving across the operator new too:

  D.14580.__obj =3D *obj_2(D);
  _6 =3D operator new (48);
  MEM[(struct MyClass2 *)_6].f =3D D.14580;


More obvious Reduced testcase:
```
struct MyClass
{
    unsigned long long arr[128];
};

[[gnu::noipa]]
void sink(void *m){}
void gg(MyClass &a)
{
  MyClass c =3D a;
  MyClass *b =3D new MyClass;
  *b =3D c;
  sink(b);
}
```

There might be a dup of this issue too.=