From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id ED6833854824; Mon, 19 Oct 2020 07:22:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org ED6833854824 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/97464] Missed redundant store optimization opportunity Date: Mon, 19 Oct 2020 07:22:16 +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: 11.0 X-Bugzilla-Keywords: alias, missed-optimization X-Bugzilla-Severity: normal 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: everconfirmed bug_status cc component keywords cf_reconfirmed_on Message-ID: In-Reply-To: References: 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 07:22:17 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D97464 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC| |rguenth at gcc dot gnu.org Component|c++ |tree-optimization Keywords| |alias, missed-optimization Last reconfirmed| |2020-10-19 --- Comment #1 from Richard Biener --- In GCCs memory model x and y can still point to the same memory, the only thing that hints at this not being the case is the load from x at the --x; statement but we're eliminating this load (using TBAA) with the store from the ++x statement which means we get to see (at the store elimination phase) int tem =3D x; y =3D 1; x =3D tem; and here the store to x is necessary because x and y may now point to the same storage, each ending lifetime of the int/float object eventually live previously at the location. So yes, before eliminating dead code after eliminating redundancies we could have seen the store is not necessary (actually we still don't use the present load to do so). So, it's a difficult one. And I believe we have a duplicate report somewhe= re.=