[Bug tree-optimization/104288] [11/12 Regression] EVRP null pointer check removal for strcmp (and maybe others) is not flow senative

["rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #8 from rguenther at suse dot de <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=104288
> 
> --- Comment #7 from Andrew Macleod <amacleod at redhat dot com> ---
> I'm contemplating the situation.  The trick is to find something with minimal
> change that is functionally acceptable.   I think the goal for this release
> would be to continue to get vrp111.c, and simply not get it in the problematic
> 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-out 
> the block for now.  
> 
> Effectively: if no dominator block contains non-null then whatever the first
> 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.  
> 
> 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? ;)