[Bug middle-end/109505] (t | 15) & svcntb() causes an OOM/ICE

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

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

--- Comment #20 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:0feece18e6993d02f24a9381ddb5420bb4509554

commit r13-7365-g0feece18e6993d02f24a9381ddb5420bb4509554
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Sun May 21 13:36:56 2023 +0200

    atch.pd: Ensure (op CONSTANT_CLASS_P CONSTANT_CLASS_P) is simplified
[PR109505]

    On the following testcase we hang, because POLY_INT_CST is
CONSTANT_CLASS_P,
    but BIT_AND_EXPR with it and INTEGER_CST doesn't simplify and the
    (x | CST1) & CST2 -> (x & CST2) | (CST1 & CST2)
    simplification actually relies on the (CST1 & CST2) simplification,
    otherwise it is a deoptimization, trading 2 ops for 3 and furthermore
    running into
    /* Given a bit-wise operation CODE applied to ARG0 and ARG1, see if both
       operands are another bit-wise operation with a common input.  If so,
       distribute the bit operations to save an operation and possibly two if
       constants are involved.  For example, convert
         (A | B) & (A | C) into A | (B & C)
       Further simplification will occur if B and C are constants.  */
    simplification which simplifies that
    (x & CST2) | (CST1 & CST2) back to
    CST2 & (x | CST1).
    I went through all other places I could find where we have a simplification
    with 2 CONSTANT_CLASS_P operands and perform some operation on those two,
    while the other spots aren't that severe (just trade 2 operations for
    another 2 if the two constants don't simplify, rather than as in the above
    case trading 2 ops for 3), I still think all those spots really intend
    to optimize only if the 2 constants simplify.

    So, the following patch adds to those a ! modifier to ensure that,
    even at GENERIC that modifier means !EXPR_P which is exactly what we want
    IMHO.

    2023-05-21  Jakub Jelinek  <jakub@redhat.com>

            PR tree-optimization/109505
            * match.pd ((x | CST1) & CST2 -> (x & CST2) | (CST1 & CST2),
            Combine successive equal operations with constants,
            (A +- CST1) +- CST2 -> A + CST3, (CST1 - A) +- CST2 -> CST3 - A,
            CST1 - (CST2 - A) -> CST3 + A): Use ! on ops with 2
CONSTANT_CLASS_P
            operands.

            * gcc.target/aarch64/sve/pr109505.c: New test.

    (cherry picked from commit f211757f6fa9515e3fd1a4f66f1a8b48e500c9de)