From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id CC3AF3858439; Wed, 1 Dec 2021 16:02:01 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CC3AF3858439 From: "law at gcc dot 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 16:02:01 +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: law 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: 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: Wed, 01 Dec 2021 16:02:01 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D82090 --- Comment #6 from Jeffrey A. Law --- I never explored the idea, but Bodik has a discussion of recording infeasib= le paths in the CFG which would seem to address this issue. He was using the concept in the context of coverage analysis -- the idea being if you were supposed to be providing 100% coverage, then you have to know if there are paths that simply can't be executed at runtime that were left in the CFG.=20 Anyway... If we find a thread, but fail to optimize it because of the cost -- we reco= rd data in the CFG on the path infeasibility. The uninit pass (or any pass for that matter) could then query that data and realize the path isn't feasible= and suppress the warning in that case. My concern with Bodik's approach is the marking and keeping those markings up-to-date through the pipeline. So that's one approach. The other is to introduce the solver into the predicate analysis pass which starts to touch on other ideas I've had. Namely that thread discovery and predicate analysis are closely related. ie, we could be using predicate analysis to discover more threading opportunities and we could be using the path solver to prune out infeasible paths for the uninit (and other) passes= by integrating path solving into predicate analysis. What you've done is the first step in this direction.=