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 928ED3858428; Tue,  6 Jun 2023 08:30:08 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 928ED3858428
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1686040208;
	bh=2I8oIfZfdqB3iBpp16TVqYSREXh1GQ5F05GYggbP9Jg=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=fOYv461fz1+zpwwyx+eKZm41O4ecHOjKrbQK86Q9bEAJjXCBeYW5J2oHNn5voQh0x
	 zC9pgoxAOUx1urWIeSWiYlFc+v561Qc1EdP4/vdmKhyvHIaCMp4ipzCCZHwgAe20Qd
	 YDt6eOaDwxI/ob2CveY19BsncTvgsmGIPXB8LlXE=
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, 06 Jun 2023 08:29:58 +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: rguenth 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: cc
Message-ID: <bug-110035-4-SIxxCsrwCC@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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aagarwa at gcc dot gnu.org,
                   |                            |amonakov at gcc dot gnu.org

--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Pontakorn Prasertsuk from comment #12)
> I notice that GCC also does not optimize this case:
> https://godbolt.org/z/7oGqjqqz4

Yes.  To quote:

#include <array>
#include <cstdint>
#include <cstdlib>
#include <iostream>

struct MyClass {
    std::array<uint64_t, 6> arr;
};

MyClass globalA;

// Prevent optimization
void sink(MyClass *m) { std::cout << m->arr[0] << std::endl; }

void __attribute__((noinline)) gg(MyClass &a) {
    MyClass c =3D a;
    MyClass *b =3D (MyClass *)malloc(sizeof(MyClass));
    *b =3D c;
    sink(b);
}

and we do RTL expansion from

  <bb 2> [local count: 1073741824]:
  vect_c_arr__M_elems_0_6.31_25 =3D MEM <vector(2) long unsigned int> [(long
unsigned int *)a_2(D)];
  vect_c_arr__M_elems_0_6.32_27 =3D MEM <vector(2) long unsigned int> [(long
unsigned int *)a_2(D) + 16B];
  vect_c_arr__M_elems_0_6.33_29 =3D MEM <vector(2) long unsigned int> [(long
unsigned int *)a_2(D) + 32B];
  b_4 =3D malloc (48);
  MEM <vector(2) long unsigned int> [(long unsigned int *)b_4] =3D
vect_c_arr__M_elems_0_6.31_25;
  MEM <vector(2) long unsigned int> [(long unsigned int *)b_4 + 16B] =3D
vect_c_arr__M_elems_0_6.32_27;
  MEM <vector(2) long unsigned int> [(long unsigned int *)b_4 + 32B] =3D
vect_c_arr__M_elems_0_6.33_29;
  sink (b_4); [tail call]

note that the temporary was elided but we specifically avoid TER
(some magic scheduling of stmts in a basic-block) to cross function
calls and there's no optimization phase that would try to optimize
register pressure over calls.  In this case we want to sink the
loads across the call, in other cases we want to avoid doing so.
In the end this would be a job for a late running pass that factors
in things like register pressure and the set of call clobbered register.

I'll note that -fschedule-insns doesn't seem to have any effect here,
but I also remember that scheduling around calls was recently fiddled with,
specifically in r13-5154-g733a1b777f16cd which restricts motion even
with -fsched-pressure (not sure how that honors call clobbered regs).

In the above case the GPR for a_2(D) would be needed after the call
(but there are not call clobbered GPRs) but the three data vectors
in xmm would no longer be live across the call (and all vector registers
are call clobbered on x86).

Of course I'm not sure at all whether RTL scheduling can disambiguate
against a 'malloc' call.=