[Bug tree-optimization/98954] New: Failure to optimize left shift+and pattern

[Bug tree-optimization/98954] New: Failure to optimize left shift+and pattern

[gabravier at gmail dot com]

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

            Bug ID: 98954
           Summary: Failure to optimize left shift+and pattern
           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(uint8_t m)
{
    return !((m << 1) & 0xFF);
}

This can be optimized to `return !(m & 0x7F);`. This transformation is done by
LLVM, but not by GCC.

[Bug tree-optimization/98954] Failure to optimize left shift+and pattern

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
   Last reconfirmed|                            |2021-02-28
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The generic transformation is
((X << CST0) & CST1) == 0
to
0 == (X & (CST1 >> CST0))

Note I think 0 could be replaced with CST2 but I am not 100% I could get it
correct.

[Bug tree-optimization/98954] ((X << CST0) & CST1) == 0 is not optimized to 0 == (X & (CST1 >> CST0))

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |pinskia at gcc dot gnu.org

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I have a partial patch.

[Bug tree-optimization/98954] ((X << CST0) & CST1) == 0 is not optimized to 0 == (X & (CST1 >> CST0))

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Created attachment 50271
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50271&action=edit
partial patch

This is the partial patch (and still need a testcase added too).
It fixes:
_Bool f(unsigned m)
{
    return !((m << 1) & 0xFF);
}

[Bug tree-optimization/98954] ((X << CST0) & CST1) == 0 is not optimized to 0 == (X & (CST1 >> CST0))

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=64992

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This is actually the general case of PR 64992 where CST1 in that case is just a
mask of all 1s.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64992#c8

[Bug tree-optimization/98954] ((X << CST0) & CST1) == 0 is not optimized to 0 == (X & (CST1 >> CST0))

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #50271|0                           |1
        is obsolete|                            |

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Created attachment 51911
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51911&action=edit
New patch

New partial patch, still need testcases. But this fixes this bug, PR 98956 and
PR 64992 .

[Bug tree-optimization/98954] ((X << CST0) & CST1) == 0 is not optimized to 0 == (X & (CST1 >> CST0))

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Roger Sayle <sayle@gcc.gnu.org>:

https://gcc.gnu.org/g:6fc14f1963dfefead588a4cd8902d641ed69255c

commit r13-2005-g6fc14f1963dfefead588a4cd8902d641ed69255c
Author: Roger Sayle <roger@nextmovesoftware.com>
Date:   Tue Aug 9 18:54:43 2022 +0100

    middle-end: Optimize ((X >> C1) & C2) != C3 for more cases.

    Following my middle-end patch for PR tree-optimization/94026, I'd promised
    Jeff Law that I'd clean up the dead-code in fold-const.cc now that these
    optimizations are handled in match.pd.  Alas, I discovered things aren't
    quite that simple, as the transformations I'd added avoided cases where
    C2 overlapped with the new bits introduced by the shift, but the original
    code handled any value of C2 provided that it had a single-bit set (under
    the condition that C3 was always zero).

    This patch upgrades the transformations supported by match.pd to cover
    any values of C2 and C3, provided that C1 is a valid bit shift constant,
    for all three shift types (logical right, arithmetic right and left).
    This then makes the code in fold-const.cc fully redundant, and adds
    support for some new (corner) cases not previously handled.  If the
    constant C1 is valid for the type's precision, the shift is now always
    eliminated (with C2 and C3 possibly updated to test the sign bit).

    Interestingly, the fold-const.cc code that I'm now deleting was originally
    added by me back in 2006 to resolve PR middle-end/21137.  I've confirmed
    that those testcase(s) remain resolved with this patch (and I'll close
    21137 in Bugzilla).  This patch also implements most (but not all) of the
    examples mentioned in PR tree-optimization/98954, for which I have some
    follow-up patches.

    2022-08-09  Roger Sayle  <roger@nextmovesoftware.com>
                Richard Biener  <rguenther@suse.de>

    gcc/ChangeLog
            PR middle-end/21137
            PR tree-optimization/98954
            * fold-const.cc (fold_binary_loc): Remove optimizations to
            optimize ((X >> C1) & C2) ==/!= 0.
            * match.pd (cmp (bit_and (lshift @0 @1) @2) @3): Remove wi::ctz
            check, and handle all values of INTEGER_CSTs @2 and @3.
            (cmp (bit_and (rshift @0 @1) @2) @3): Likewise, remove wi::clz
            checks, and handle all values of INTEGER_CSTs @2 and @3.

    gcc/testsuite/ChangeLog
            PR middle-end/21137
            PR tree-optimization/98954
            * gcc.dg/fold-eqandshift-4.c: New test case.

[Bug tree-optimization/98954] ((X << CST0) & CST1) == 0 is not optimized to 0 == (X & (CST1 >> CST0))

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Roger Sayle <sayle@gcc.gnu.org>:

https://gcc.gnu.org/g:418b71c0d535bf91df78bad2e198c57934682eaa

commit r13-2048-g418b71c0d535bf91df78bad2e198c57934682eaa
Author: Roger Sayle <roger@nextmovesoftware.com>
Date:   Mon Aug 15 17:39:47 2022 +0100

    PR tree-optimization/64992: (B << 2) != 0 is B when B is Boolean.

    This patch resolves both PR tree-optimization/64992 and PR
    tree-optimization/98956 which are missed optimization enhancement
    request, for which Andrew Pinski already has a proposed solution
    (related to a fix for PR tree-optimization/98954).  Yesterday,
    I proposed an alternate improved patch for PR98954, which although
    superior in most respects, alas didn't address this case [which
    doesn't include a BIT_AND_EXPR], hence this follow-up fix.

    For many functions, F(B), of a (zero-one) Boolean value B, the
    expression F(B) != 0 can often be simplified to just B.  Hence
    "(B * 5) != 0" is B, "-B != 0" is B, "bswap(B) != 0" is B,
    "(B >>r 3) != 0" is B.  These are all currently optimized by GCC,
    with the strange exception of left shifts by a constant (possibly
    due to the undefined/implementation defined behaviour when the
    shift constant is larger than the first operand's precision).
    This patch adds support for this particular case, when the shift
    constant is valid.

    2022-08-15  Roger Sayle  <roger@nextmovesoftware.com>

    gcc/ChangeLog
            PR tree-optimization/64992
            PR tree-optimization/98956
            * match.pd (ne (lshift @0 @1) 0): Simplify (X << C) != 0 to X
            when X is zero_one_valued_p and the shift constant C is valid.
            (eq (lshift @0 @1) 0): Likewise, simplify (X << C) == 0 to !X
            when X is zero_one_valued_p and the shift constant C is valid.

    gcc/testsuite/ChangeLog
            PR tree-optimization/64992
            * gcc.dg/pr64992.c: New test case.

[Bug tree-optimization/98954] ((X << CST0) & CST1) == 0 is not optimized to 0 == (X & (CST1 >> CST0))

[roger at nextmovesoftware dot com]

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

Roger Sayle <roger at nextmovesoftware dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.0
             Status|ASSIGNED                    |RESOLVED
                 CC|                            |roger at nextmovesoftware dot com
         Resolution|---                         |FIXED

--- Comment #8 from Roger Sayle <roger at nextmovesoftware dot com> ---
This should now be fixed on mainline.