[Bug tree-optimization/96702] New: Failure to optimize comparisons involving result of subtraction

[Bug tree-optimization/96702] New: Failure to optimize comparisons involving result of subtraction

[gabravier at gmail dot com]

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

            Bug ID: 96702
           Summary: Failure to optimize comparisons involving result of
                    subtraction
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gabravier at gmail dot com
  Target Milestone: ---

bool f(int a, int b)
{
    int c = (a - b);
    return c >= a && c != 0;
}

This can be optimized to `return (b <= 0) && (a != b);`. This transformation is
done by LLVM, but not by GCC.

[Bug tree-optimization/96702] Failure to optimize comparisons involving result of subtraction

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement

[Bug tree-optimization/96702] Failure to optimize comparisons involving result of subtraction

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2021-08-17
     Ever confirmed|0                           |1

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed.

The problem is c is used twice.
we handle both optimizations just fine alone, just not when together.
There might be either a :s that maybe should not be there in match.pd or an
explict check for used more than once.

[Bug tree-optimization/96702] Failure to optimize comparisons involving result of subtraction

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The comment says:
/* To detect overflow in unsigned A - B, A < B is simpler than A - B > A.
   However, the detection logic for SUB_OVERFLOW in tree-ssa-math-opts.cc
   expects the long form, so we restrict the transformation for now.  */
(for cmp (gt le)
 (simplify
  (cmp:c (minus@2 @0 @1) @0)
  (if (single_use (@2)

I am curious if that is still true ...

[Bug tree-optimization/96702] Failure to optimize comparisons involving result of subtraction

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
wait that is for unsigned types and we don't have an unsigned type here ..

[Bug tree-optimization/96702] Failure to optimize comparisons involving result of subtraction

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The pattern:
/* X - Y < X is the same as Y > 0 when there is no overflow.
   For equality, this is also true with wrapping overflow.  */
(for op (simple_comparison)
 (simplify
  (op:c @0 (minus@2 @0 @1))
  (if (ANY_INTEGRAL_TYPE_P (TREE_TYPE (@0))
       && (TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (@0))
           || ((op == EQ_EXPR || op == NE_EXPR)
               && TYPE_OVERFLOW_WRAPS (TREE_TYPE (@0))))
       && (CONSTANT_CLASS_P (@1) || single_use (@2)))
   (op @1 { build_zero_cst (TREE_TYPE (@1)); }))))

https://gcc.gnu.org/pipermail/gcc-patches/2017-October/484606.html describes
why there was a single use but I wonder if ranger now does not cause the need
for the single_use ....

[Bug tree-optimization/96702] Failure to optimize comparisons involving result of subtraction

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #4)
> The pattern:
> /* X - Y < X is the same as Y > 0 when there is no overflow.
>    For equality, this is also true with wrapping overflow.  */
> (for op (simple_comparison)
>  (simplify
>   (op:c @0 (minus@2 @0 @1))
>   (if (ANY_INTEGRAL_TYPE_P (TREE_TYPE (@0))
>        && (TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (@0))
> 	   || ((op == EQ_EXPR || op == NE_EXPR)
> 	       && TYPE_OVERFLOW_WRAPS (TREE_TYPE (@0))))
>        && (CONSTANT_CLASS_P (@1) || single_use (@2)))
>    (op @1 { build_zero_cst (TREE_TYPE (@1)); }))))
> 
> https://gcc.gnu.org/pipermail/gcc-patches/2017-October/484606.html describes
> why there was a single use but I wonder if ranger now does not cause the
> need for the single_use ....

Looks like that issue was fixed in GCC 9 so maybe the 2 uses of single_use can
be removed ...