[Bug tree-optimization/110637] New: (type)(zeroonep !=/== 0) should be optimized as (type)zeroonep/zeroonep^1 earlier than vrp

[Bug tree-optimization/110637] New: (type)(zeroonep !=/== 0) should be optimized as (type)zeroonep/zeroonep^1 earlier than vrp

[pinskia at gcc dot gnu.org]

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

            Bug ID: 110637
           Summary: (type)(zeroonep !=/== 0) should be optimized as
                    (type)zeroonep/zeroonep^1 earlier than vrp
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Keywords: missed-optimization
          Severity: enhancement
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
int f(int t)
{
 t &= 1;
 return t != 0;
}
```
Currently this only gets optimized at -O2 (due to VRP) to:
  _4 = t_1(D) & 1;
  return _4;

Likewise for:
```
int g(int t)
{
 t &= 1;
 return t == 0;
}
```

This was originally how I was going to solve PR 110539 but when we should
optimize to those gets in the way of other optimizations so I decided to fix PR
110539 a different way.

[Bug tree-optimization/110637] (type)(zeroonep !=/== 0) should be optimized as (type)zeroonep/zeroonep^1 earlier than vrp

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-07-12
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
See https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623881.html and the
reply.

[Bug tree-optimization/110637] (type)(zeroonep !=/== 0) should be optimized as (type)zeroonep/zeroonep^1 earlier than vrp

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Maybe zero_one_valued_p needs a

(match zero_one_valued_p
 (bit_and @0 integer_onep))

?  (hopefully for signed 1-bit precision that doesn't match)

[Bug tree-optimization/110637] (type)(zeroonep !=/== 0) should be optimized as (type)zeroonep/zeroonep^1 earlier than vrp

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The trunk branch has been updated by Andrew Pinski <pinskia@gcc.gnu.org>:

https://gcc.gnu.org/g:85c5efcffed19ca6160eeecc2d4faebd9fee63aa

commit r14-6420-g85c5efcffed19ca6160eeecc2d4faebd9fee63aa
Author: Andrew Pinski <quic_apinski@quicinc.com>
Date:   Sat Nov 11 15:54:10 2023 -0800

    MATCH: (convert)(zero_one !=/== 0/1) for outer type and zero_one type are
the same

    When I moved two_value to match.pd, I removed the check for the {0,+-1}
    as I had placed it after the {0,+-1} case for cond in match.pd.
    In the case of {0,+-1} and non boolean, before we would optmize those
    case to just `(convert)a` but after we would get `(convert)(a != 0)`
    which was not handled anyways to just `(convert)a`.
    So this adds a pattern to match `(convert)(zeroone != 0)` and simplify
    to `(convert)zeroone`.

    Also this optimizes (convert)(zeroone == 0) into (zeroone^1) if the
    type match. Removing the opposite transformation from fold.
    The opposite transformation was added with
    https://gcc.gnu.org/pipermail/gcc-patches/2006-February/190514.html
    It is no longer considered the canonicalization either, even VRP will
    transform it back into `(~a) & 1` so removing it is a good idea.

    Note the testcase pr69270.c needed a slight update due to not matching
    exactly a scan pattern, this update makes it more robust and will match
    before and afterwards and if there are other changes in this area too.

    Note the testcase gcc.target/i386/pr110790-2.c needs a slight update
    for better code generation in LP64 bit mode.

    Bootstrapped and tested on x86_64-linux-gnu with no regressions.

    gcc/ChangeLog:

            PR tree-optimization/111972
            PR tree-optimization/110637
            * match.pd (`(convert)(zeroone !=/== CST)`): Match
            and simplify to ((convert)zeroone){,^1}.
            * fold-const.cc (fold_binary_loc): Remove
            transformation of `(~a) & 1` and `(a ^ 1) & 1`
            into `(convert)(a == 0)`.

    gcc/testsuite/ChangeLog:

            * gcc.dg/tree-ssa/pr110637-1.c: New test.
            * gcc.dg/tree-ssa/pr110637-2.c: New test.
            * gcc.dg/tree-ssa/pr110637-3.c: New test.
            * gcc.dg/tree-ssa/pr111972-1.c: New test.
            * gcc.dg/tree-ssa/pr69270.c: Update testcase.
            * gcc.target/i386/pr110790-2.c: Update testcase.
            * gcc.dg/fold-even-1.c: Removed.

    Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>

[Bug tree-optimization/110637] (type)(zeroonep !=/== 0) should be optimized as (type)zeroonep/zeroonep^1 earlier than vrp

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |14.0
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Fixed.

We decided that if the types don't match, we should keep around the `== 0` .