[Bug tree-optimization/97909] New: expr_not_equal_to (mainly in match.pd) vs. ranger

["jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

            Bug ID: 97909
           Summary: expr_not_equal_to (mainly in match.pd) vs. ranger
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

Something I've noticed today and filing this so that it isn't forgotten.
Various places in match.pd use expr_not_equal_to to decide based on value
ranges whether to perform something or not.
This uses just SSA_NAME_RANGE_INFO under the hood right now.
Would be nice to use range for this; bet we'd need a way for match.pd to
provide
extra information on where it is, so either a gimple *, or perhaps for match.pd
it would be easier to provide a tree, which would be usually SSA_NAME of the
lhs of the statement we want to query the range at, and then the function would
check if the tree is an SSA_NAME and in that case talk to ranger and ask about
range at the start of the SSA_NAME_DEF_STMT.
E.g. we have:
/* X % -Y is the same as X % Y.  */
(simplify
 (trunc_mod @0 (convert? (negate @1)))
 (if (INTEGRAL_TYPE_P (type)
      && !TYPE_UNSIGNED (type)
      && !TYPE_OVERFLOW_TRAPS (type)
      && tree_nop_conversion_p (type, TREE_TYPE (@1))
      /* Avoid this transformation if X might be INT_MIN or
         Y might be -1, because we would then change valid
         INT_MIN % -(-1) into invalid INT_MIN % -1.  */
      && (expr_not_equal_to (@0, wi::to_wide (TYPE_MIN_VALUE (type)))
          || expr_not_equal_to (@1, wi::minus_one (TYPE_PRECISION
                                                        (TREE_TYPE (@1))))))
  (trunc_mod @0 (convert @1))))
so if expr_not_equal_to has a defaulted = NULL_TREE extra argument, the second
expr_not_equal_to could pass as the third argument @2 where it would be
(negate@2 @1).  Unclear if we have something to pass for the trunc_mod's LHS or
how to identify that statement.

Testcase for exactly this could be:
  int x = foo (), y;
  if (x != -1)
    y = z % -x;
  else
    y = -1; 
where we could optimize the y = z % -x; to y = z % x; but don't currently,
because we know that x is not -1 only in certain paths and SSA_NAME_RANGE_INFO
can't reflect that.