Bug 110637 - (type)(zeroonep !=/== 0) should be optimized as (type)zeroonep/zeroonep^1 earlier than vrp
Summary: (type)(zeroonep !=/== 0) should be optimized as (type)zeroonep/zeroonep^1 ear...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 14.0
: P3 enhancement
Target Milestone: 14.0
Assignee: Not yet assigned to anyone
URL:
Keywords: missed-optimization
Depends on:
Blocks:
 
Reported: 2023-07-12 07:25 UTC by Andrew Pinski
Modified: 2023-12-11 15:58 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2023-07-12 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Pinski 2023-07-12 07:25:56 UTC
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.
Comment 1 Andrew Pinski 2023-07-12 07:26:43 UTC
See https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623881.html and the reply.
Comment 2 Richard Biener 2023-07-12 08:06:15 UTC
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)
Comment 3 GCC Commits 2023-12-11 15:56:43 UTC
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>
Comment 4 Andrew Pinski 2023-12-11 15:58:43 UTC
Fixed.

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