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 471823858D20; Tue, 30 May 2023 11:55:46 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 471823858D20
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1685447746;
	bh=Kkar31aCbLjmjPsJnKo2cs/a0ynxpec/TnzrKm0MIbI=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=rFHPWI5MY8K8t4ZJfjakboEXlUEx28LjvxVEJKIBZYZyQRiWgn/O9cPiobIrnJ6y7
	 lxHT08hPqSoT+ylXuu2Lloc6zBafD0SAfkrvjV+vwLPijwAO1kL+szX9tdnqcfuGDQ
	 zc5xy0bxx0llhMktICToIE2LO3Dw9D3PXNL9EABk=
From: "rguenth 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 11:55:45 +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: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
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-110035-4-QbqksolMWI@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

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

void ff (struct MyClass & obj)
{
  vector(2) long unsigned int vect_SR.16;
  vector(2) long unsigned int vect_SR.15;
  vector(2) long unsigned int vect_SR.14;
  void * _6;

  <bb 2> [local count: 1073741824]:
  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]

and the issue is that 'operator new (48)' can alter what 'obj' points to,
so we cannot move the loads across the call and we get spilling.

There is no inter-procedural analysis in GCC that would tell us that
'obj_2(D)' (the MyClass & obj argument of ff) does not point to an
object that did not escape.  In fact 'ff' has global visibility
and it might have other callers.

If you add -fwhole-program then you get the function inlined to main and

main:
.LFB652:
        .cfi_startproc
        subq    $8, %rsp
        .cfi_def_cfa_offset 16
        movl    $48, %edi
        call    _Znwm
        movq    $0, (%rax)
        movq    %rax, %rdi
        movq    $0, 8(%rax)
        movq    $0, 16(%rax)
        movq    $0, 24(%rax)
        movq    $0, 32(%rax)
        movq    $0, 40(%rax)
        call    _Z14HandleMyClass2Pv
        xorl    %eax, %eax
        addq    $8, %rsp
        .cfi_def_cfa_offset 8
        ret

(not using vectors because 'main' is considered cold).  Do you cite an
inline copy of ff() for clang?=