https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96564
--- Comment #15 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Richard Biener from comment #13)
> (In reply to Jeffrey A. Law from comment #12)
> > So I think we could solve this with a bit of help from the alias oracle. We
> > have the routine ptrs_compare_unequal, but points-to-null is going to get
> > in the way.
> >
> > I think VRP and DOM have enough information to rule out NULL for both
> > objects in question. So if we could query the points-to information,
> > ignoring NULL then we could likely solve this particular bug.
> >
> > Essentially VRP or DOM would prove NULL isn't in the set of possible values
> > at the comparison point. Then we query the alias information ignoring NULL.
> > Voila we compute a static result for the comparison of the two pointers and
> > the problematical block becomes unreachable and the bogus warning goes away.
> >
> > Richi, any thoughts in viability of such an API?
>
> We now treat pt.null conservatively and track non-null-ness derived from
> range-info in it. That means when VRP/DOM can prove a pointer is always
> not NULL they can do set_ptr_nonnull (p) on it.
>
> This means the
>
> /* ??? We'd like to handle ptr1 != NULL and ptr1 != ptr2
> but those require pt.null to be conservatively correct. */
>
> is no longer true and we could finally implement it, like with
>
> diff --git a/gcc/tree-ssa-alias.cc b/gcc/tree-ssa-alias.cc
> index e7c1c1aa624..5b6d9e0aa6a 100644
> --- a/gcc/tree-ssa-alias.cc
> +++ b/gcc/tree-ssa-alias.cc
> @@ -479,9 +479,25 @@ ptrs_compare_unequal (tree ptr1, tree ptr2)
> }
> return !pt_solution_includes (&pi->pt, obj1);
> }
> -
> - /* ??? We'd like to handle ptr1 != NULL and ptr1 != ptr2
> - but those require pt.null to be conservatively correct. */
> + else if (TREE_CODE (ptr1) == SSA_NAME)
> + {
> + struct ptr_info_def *pi1 = SSA_NAME_PTR_INFO (ptr1);
> + if (!pi1
> + || pi1->pt.vars_contains_restrict
> + || pi1->pt.vars_contains_interposable)
> + return false;
> + if (integer_zerop (ptr2) && !pi1->pt.null)
> + return true;
> + if (TREE_CODE (ptr2) == SSA_NAME)
> + {
> + struct ptr_info_def *pi2 = SSA_NAME_PTR_INFO (ptr2);
> + if (!pi2
> + || pi2->pt.vars_contains_restrict
> + || pi2->pt.vars_contains_interposable)
> + if (!pi1->pt.null || !pi2->pt.null)
> + return !pt_solutions_intersect (&pi1->pt, &pi2->pt);
> + }
> + }
>
> return false;
> }
>
>
> but the testcase shows the non-null-ness is only conditional which means
> we'd have to use a range query above which necessarily falls back to
> the global ranges given we don't have any context available here. The
> old EVRP adjusted global ranges during the walk but this is no longer done.
>
You mean it lied? because x_1 is not NULL until after _8 = *x_1(D); executes.
It can still be NULL on that stmt can it not? Did it reset the global value
afterwards?
Contextually ranger knows both are non-null at EVRP time:
a.0_27 : [irange] int[0:D.xxxx] * [1, +INF]
2->3 (T) x_1(D) : [irange] int * [1, +INF]
2->3 (T) a.0_27 : [irange] int[0:D.xxxx] * [1, +INF]
2->4 (F) x_1(D) : [irange] int * [1, +INF]
2->4 (F) a.0_27 : [irange] int[0:D.xxxx] * [1, +INF]
So we know x_1 is non-NULL after the de-reference for the rest of the block
(and function). It also sets a.0_27 globally to be [1, +INF].
> Note it's enough that one pointer is nonnull, so for your idea the
> API could be extended with a bool one_ptr_nonnull parameter.
ranger currently sets a.0 globally to be non-null in EVRP.
