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

["amacleod at redhat dot com" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #9 from Andrew Macleod <amacleod at redhat dot com> ---
 risk/churn.
> >  At least that is what I'M currently trying.  would this be OK?
> 
> Let's see what you can come up with.


> (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? ;)

Intention has always been to introduce a range_after_stmt to the API for
side-effects, which would merge some aspects of the way EVRP did things.

I have a patchset which I will submit shortly.. once everything passes mustard.
Its actually not that significant of a change.

Ranger currently tracks non-null for an ssa-name in blocks with a single bit. 
I change that to 2 bits so we can tell if all uses in the block have the
non-null property, or if there are some uses which do not have the property.

range-on-entry is changed to only check the dominators, and range-of-expr is
changed to only apply the non-null property if the entire block has only uses
with the non-null property.

After trying to simply/fold each statement in the domwalk, I now check if the
statement sets the non-null property. If so, then mark this block as non-null
throughout, and any further queries through range_of_expr within this block
will now pick up the non-null property. 

This allows us the flexibility of EVRPs granular walk, while remaining
conservative with any on demand clients.  This also solves the problematic
testcase I showed earlier, producing the desired:
  _1 = p_3(D) == 0B;
  _2 = (int) _1;
  h (_2);
  foo (p_3(D));
  return;

Anyway, patch coming soon. I believe it to be low risk as the changes are all
localized, and results should always be more conservative with the additonal 
granularity.