[Bug target/100048] [10/11 Regression] Wrongful CSE'ing of SVE predicates.

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tamar Christina <tnfch...@gcc.gnu.org>:

https://gcc.gnu.org/g:8535755af70f819d820553b2e73e72a16a984599

commit r11-8223-g8535755af70f819d820553b2e73e72a16a984599
Author: Tamar Christina <tamar.christ...@arm.com>
Date:   Fri Apr 16 16:58:50 2021 +0100

    SVE: Fix wrong sve predicate split (PR100048)

    The attached testcase generates the following paradoxical subregs when
creating
    the predicates.

    (insn 22 21 23 2 (set (reg:VNx8BI 100)
            (subreg:VNx8BI (reg:VNx2BI 103) 0))
         (expr_list:REG_EQUAL (const_vector:VNx8BI [
                    (const_int 1 [0x1])
                    (const_int 0 [0])
                    (const_int 1 [0x1])
            (const_int 0 [0]) repeated x5
                ])
            (nil)))

    and

    (insn 15 14 16 2 (set (reg:VNx8BI 96)
            (subreg:VNx8BI (reg:VNx2BI 99) 0))
         (expr_list:REG_EQUAL (const_vector:VNx8BI [
                    (const_int 1 [0x1])
                    (const_int 0 [0]) repeated x7
                ])
            (nil)))

    This causes CSE to incorrectly think that the two predicates are equal
because
    some of the significant bits get ignored due to the subreg.

    The attached patch instead makes it so it always looks at all 16-bits of
the
    predicate, but in turn means we need to generate a TRN that matches the
expected
    result mode.  In effect in RTL we keep the mode as VNx16BI but during
codegen
    re-interpret them as the mode the predicate instruction wanted:

    (insn 10 9 11 2 (set (reg:VNx8BI 96)
            (subreg:VNx8BI (reg:VNx16BI 99) 0))
         (expr_list:REG_EQUAL (const_vector:VNx8BI [
                    (const_int 1 [0x1])
                    (const_int 0 [0]) repeated x7
                ])
            (nil)))

    Which needed correction to the TRN pattern.  A new TRN1_CONV unspec is
    introduced which allows one to keep the arguments as VNx16BI but encode the
    instruction as a type of the last operand.

    (insn 9 8 10 2 (set (reg:VNx16BI 99)
            (unspec:VNx16BI [
                    (reg:VNx16BI 97)
                    (reg:VNx16BI 98)
                    (reg:VNx2BI 100)
                ] UNSPEC_TRN1_CONV))
            (nil))

    This allows us remove all the paradoxical subregs and end up with

    (insn 16 15 17 2 (set (reg:VNx8BI 101)
            (subreg:VNx8BI (reg:VNx16BI 104) 0))
            (expr_list:REG_EQUAL (const_vector:VNx8BI [
                    (const_int 1 [0x1])
                    (const_int 0 [0])
                    (const_int 1 [0x1])
                    (const_int 0 [0]) repeated x5
                ])
            (nil)))

    gcc/ChangeLog:

            PR target/100048
            * config/aarch64/aarch64-sve.md (@aarch64_sve_trn1_conv<mode>):
New.
            * config/aarch64/aarch64.c (aarch64_expand_sve_const_pred_trn): Use
new
            TRN optab.
            * config/aarch64/iterators.md (UNSPEC_TRN1_CONV): New.

    gcc/testsuite/ChangeLog:

            PR target/100048
            * gcc.target/aarch64/sve/pr100048.c: New test.