Re: [PATCH] PR tree-optimization/109274 -Fix compute_operand when op1 == op2 symbolically.

[Richard Biener <richard.guenther@gmail.com>]

On Tue, Mar 28, 2023 at 3:19 PM Andrew MacLeod <amacleod@redhat.com> wrote:
>
> On 3/24/23 12:36, Jakub Jelinek wrote:
> > On Fri, Mar 24, 2023 at 11:52:30AM -0400, Andrew MacLeod wrote:
> >> Thanks.. Ive incorporated it into my commit  too.
> > Note, both my earlier version of the patch and your patch regress:
> > FAIL: gcc.dg/tree-ssa/vrp-float-3a.c scan-tree-dump-not evrp "link_error"
> > FAIL: gcc.dg/tree-ssa/vrp-float-4a.c scan-tree-dump-not evrp "link_error"
> >
> >       Jakub
> >
> OK, that was fun.
>
> I commented in the PR, but the root issue is the way I was trying to
> communicate symbolic equivalence on operands to the compute_operand
> routines.
>
> [1, 1 ]= a_1 != a_1
>
> I was creating a relation record between op1 and op2 indicating they
> were equivalent.    THis record then gets passed up the gori call chain.
>
> Reality is that this is not a true equivalence... without looking a the
> ranges, we dont know that that is true for general application, and and
> furthermore, when applied to something like a1 != a1, you can see the
> problem...
>
> Once I corrected the value_relation record to create records with the
> same operand, things went south.
>
> What we really need is to locally identify when op1 and op2 are the same
> symbol, and if there is no other information, pass it locally on that
> one statement  to the range-op handler.
>
> Then, once we have processed the statement, we invoke the handler for
> that statement to cvreate a record which is passed up the chain.
> so for:
>
>      a_1 = b_4 + 1.0
>      [1, 1] = (a_1 != a_1)
>
> compute_operand_1 starts with no relation record, recognizes
> symbolically op1 and op2 are the same, and passes EQ_EXPR locally as the
> op1_op2 relation to the handler for NE_EXPR.   That handler utilizes the
> range of op2 to detemine whether != is true or not based on knowledge
> that op1 and op2 are the same value.     (for integer always false, for
> float, takes a look at NAN) and produces a result.
>
> Before invoking compute_operand to calculate b_4 with the result of a_1,
>    handler.op1_op2_relation (lhs);
> is invoked to determine if there is a relation generated by the
> statement, which will generate  (a_1 != a_1), and pass that to compute
> operand for use in evaluating b_4.
>
> Bootstraps on x86_64-pc-linux-gnu with no regressions.  OK for trunk?

LGTM.

Thanks,
Richard.

> Andrew