From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 265AC3858D35; Tue, 1 Feb 2022 08:04:17 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 265AC3858D35 From: "rguenther at suse dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/104288] [11/12 Regression] EVRP null pointer check removal for strcmp (and maybe others) is not flow senative Date: Tue, 01 Feb 2022 08:04: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.2.1 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenther at suse dot de X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 11.3 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: Tue, 01 Feb 2022 08:04:17 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D104288 --- Comment #8 from rguenther at suse dot de --- On Mon, 31 Jan 2022, amacleod at redhat dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D104288 >=20 > --- Comment #7 from Andrew Macleod --- > I'm contemplating the situation. The trick is to find something with min= imal > change that is functionally acceptable. I think the goal for this relea= se > would be to continue to get vrp111.c, and simply not get it in the proble= matic > case.. ie, if the first use in the block is unknown and then LATER in the > block we figure out that it is non-null, we will miss that case through-o= ut=20 > the block for now.=20=20 >=20 > Effectively: if no dominator block contains non-null then whatever the fi= rst > use in a block determines will apply to the whole block, for the duration= of > the block.. but upon exit to the block, if it was non-null anywhere, then= all > following blocks get that knowledge.=20=20 >=20 > I think this could be done reasonably efficiently with a minimum of risk/= churn. > At least that is what I'M currently trying. would this be OK? Let's see what you can come up with. For ranges derived from stmts that are not the last in a BB (in which case they apply to outgoing edges) you have to strictly adhere to the notion that you have ranges incoming into a stmt and ranges outgoing so each stmt is the source of new ranges. That applies to divisions (nonzero divisor) or shifts (no out of range shift operand). But you may not apply the range to all stmts of a block (including the stmt producing the range itself). With the old EVRP scheme I failed to nicely support deriving non-zero divisor ranges for this reason for example. That makes it complicated to handle in an on-demand fashion of course since you'd need a per stmt cache that is much more difficult to manage and look up. (which is why I really did like to have the old EVRP since conceptually it's easy to have a very fine-grained "context") Practically I think it's OK for true on-demand users to have the less precise per-BB non-NULL data. But the value-range passes should really be able to keep a precise per-stmt "context". Did I say I liked the old EVRP way of doing things? ;)=