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 9B53F3858029; Wed,  1 Dec 2021 15:50:35 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9B53F3858029
From: "aldyh at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: =?UTF-8?B?W0J1ZyB0cmVlLW9wdGltaXphdGlvbi84MjA5MF0gQm9ndXMgd2Fy?=
 =?UTF-8?B?bmluZzog4oCYbWFnaWNfcOKAmSBtYXkgYmUgdXNlZCB1bmluaXRpYWxpemVk?=
 =?UTF-8?B?IGluIHRoaXMgZnVuY3Rpb24gWy1XbWF5YmUtdW5pbml0aWFsaXplZF0=?=
Date: Wed, 01 Dec 2021 15:50:35 +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: 7.2.1
X-Bugzilla-Keywords: diagnostic, missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: aldyh 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: 
Message-ID: <bug-82090-4-ypV3ERsJJj@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-82090-4@http.gcc.gnu.org/bugzilla/>
References: <bug-82090-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
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Dec 2021 15:50:35 -0000

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D82090

--- Comment #5 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
[from the POC patch]

It seems that every missed thread (due to inability of the threader,
or due to cost restraints) is a potential false positive for the
uninit code.  Perhaps what we need is a way to identify threading
opportunities without doing the actual threading.  The attached is a
proof-of-concept that does just that.

Basically a lof of these PRs look like:

x_5 =3D PHI <UNDEF(10), x_8(20), x_10(30)>
...
...
if (cond_8)
  use(x_5);

This looks like a path from the definition of x_5 to the cond_8 check.
If the incoming path through BB10 can be determined to elide the use
of x_5, we could disregard this as a false positive.

This patch solves PR82090, but it would need to be properly
incorporated into the uninit pass.  For instance, I'm finding paths
from USE back to DEF, but the uninit pass is in a much better position
to tell us what the starting point of the path is.  It's likely to be
further up the chain through a maze of feeding PHIs.

This is just meant as a stop gap to help in reducing the false
positive rate, nothing fancy.  Maybe the work by Martin Liska and
Richi on loop unswitching would be a better solution.

Anywhoo... Maybe someone with knowledge of the uninit pass could
explore this.  Just a thought.=