On Tue, Mar 28, 2023 at 3:19 PM Andrew MacLeod <amacl...@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
