[Bug target/106069] [12/13/14/15 Regression] wrong code with -O -fno-tree-forwprop -maltivec on ppc64le

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

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

--- Comment #42 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Kewen Lin <linkw@gcc.gnu.org>:

https://gcc.gnu.org/g:812c70bf4981958488331d4ea5af8709b5321da1

commit r15-1645-g812c70bf4981958488331d4ea5af8709b5321da1
Author: Kewen Lin <linkw@linux.ibm.com>
Date:   Wed Jun 26 02:16:17 2024 -0500

    rs6000: Fix wrong RTL patterns for vector merge high/low short on LE

    Commit r12-4496 changes some define_expands and define_insns
    for vector merge high/low short, which are altivec_vmrg[hl]h.
    These defines are mainly for built-in function vec_merge{h,l}
    and some internal gen function needs.  These functions should
    consider endianness, taking vec_mergeh as example, as PVIPR
    defines, vec_mergeh "Merges the first halves (in element order)
    of two vectors", it does note it's in element order.  So it's
    mapped into vmrghh on BE while vmrglh on LE respectively.
    Although the mapped insns are different, as the discussion in
    PR106069, the RTL pattern should be still the same, it is
    conformed before commit r12-4496, but gets changed into
    different patterns on BE and LE starting from commit r12-4496.
    Similar to 32-bit element case in commit log of r15-1504, this
    16-bit element pattern on LE doesn't actually match what the
    underlying insn is intended to represent, once some optimization
    like combine does some changes basing on it, it would cause
    the unexpected consequence.  The newly constructed test case
    pr106069-2.c is a typical example for this issue on element type
    short.

    So this patch is to fix the wrong RTL pattern, ensure the
    associated RTL patterns become the same as before which can
    have the same semantic as their mapped insns.  With the
    proposed patch, the expanders like altivec_vmrghh expands
    into altivec_vmrghh_direct_be or altivec_vmrglh_direct_le
    depending on endianness, "direct" can easily show which
    insn would be generated, _be and _le are mainly for the
    different RTL patterns as endianness.

    Co-authored-by: Xionghu Luo <xionghuluo@tencent.com>

            PR target/106069
            PR target/115355

    gcc/ChangeLog:

            * config/rs6000/altivec.md (altivec_vmrghh_direct): Rename to ...
            (altivec_vmrghh_direct_be): ... this.  Add condition
BYTES_BIG_ENDIAN.
            (altivec_vmrghh_direct_le): New define_insn.
            (altivec_vmrglh_direct): Rename to ...
            (altivec_vmrglh_direct_be): ... this.  Add condition
BYTES_BIG_ENDIAN.
            (altivec_vmrglh_direct_le): New define_insn.
            (altivec_vmrghh): Adjust by calling gen_altivec_vmrghh_direct_be
            for BE and gen_altivec_vmrglh_direct_le for LE.
            (altivec_vmrglh): Adjust by calling gen_altivec_vmrglh_direct_be
            for BE and gen_altivec_vmrghh_direct_le for LE.
            (vec_widen_umult_hi_v16qi): Adjust the call to
            gen_altivec_vmrghh_direct by gen_altivec_vmrghh for BE
            and by gen_altivec_vmrglh for LE.
            (vec_widen_smult_hi_v16qi): Likewise.
            (vec_widen_umult_lo_v16qi): Adjust the call to
            gen_altivec_vmrglh_direct by gen_altivec_vmrglh for BE
            and by gen_altivec_vmrghh for LE.
            (vec_widen_smult_lo_v16qi): Likewise.
            * config/rs6000/rs6000.cc (altivec_expand_vec_perm_const): Replace
            CODE_FOR_altivec_vmrghh_direct by
            CODE_FOR_altivec_vmrghh_direct_be for BE and
            CODE_FOR_altivec_vmrghh_direct_le for LE.  And replace
            CODE_FOR_altivec_vmrglh_direct by
            CODE_FOR_altivec_vmrglh_direct_be for BE and
            CODE_FOR_altivec_vmrglh_direct_le for LE.

    gcc/testsuite/ChangeLog:

            * gcc.target/powerpc/pr106069-2.c: New test.