[Bug target/103611] GCC generates suboptimal code for SSE2/SSE4.1 64-bit integer element extraction on 32-bit x86 targets

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

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

--- 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:31048012db98f5ec9c2ba537bfd850374bdd771f

commit r12-6058-g31048012db98f5ec9c2ba537bfd850374bdd771f
Author: Roger Sayle <roger@nextmovesoftware.com>
Date:   Sat Dec 18 13:51:56 2021 +0000

    x86: PR target/103611: Splitter for DST:DI = (HI:SI<<32)|LO:SI.

    A common idiom is to create a DImode value from the "concat" of two SImode
    values, using "(long long)hi << 32 | (long long)lo", where the operation
    may be ior, xor or plus.  On x86, with -m32, the high and low parts of
    a DImode register are actually different SImode registers (typically %edx
    and %eax) so ideally this idiom should reduce to two move instructions
    (or optimally, just clever register allocation).

    Unfortunately, GCC currently performs the IOR operation above on -m32,
    and worse allocates DImode registers (split to SImode register pairs)
    for both the zero extended HI and LO values.

    Hence, for test1 from the new test case below:

    typedef int __v4si __attribute__ ((__vector_size__ (16)));
    long long test1(__v4si v) {
      unsigned int loVal = (unsigned int)v[0];
      unsigned int hiVal = (unsigned int)v[1];
      return (long long)(loVal) | ((long long)(hiVal) << 32);
    }

    we currently generate (with -m32 -O2 -msse4.1):

    test1:  subl    $28, %esp
            pextrd  $1, %xmm0, %eax
            pmovzxdq        %xmm0, %xmm1
            movq    %xmm1, 8(%esp)
            movl    %eax, %edx
            movl    8(%esp), %eax
            orl     12(%esp), %edx
            addl    $28, %esp
            orb     $0, %ah
            ret

    with this patch we now generate:

    test1:  pextrd  $1, %xmm0, %edx
            movd    %xmm0, %eax
            ret

    The fix is to recognize and split the idiom (hi<<32)|zext(lo) prior
    to register allocation on !TARGET_64BIT, simplifying this sequence to
    "highpart(dst) = hi; lowpart(dst) = lo".

    The one minor complication is that sse.md's define_insn for
    *vec_extractv4si_0_zext_sse4 can sometimes interfere with this
    optimization.  It turns out that on !TARGET_64BIT, the zero_extend:DI
    following vec_select:SI isn't free, and this insn gets split back
    into multiple instructions during later passes, but too late to
    be optimized away by this patch/reload.  Hence the last hunk of
    this patch is to restrict *vec_extractv4si_0_zext_sse4 to TARGET_64BIT.
    Checking PR target/80286, where *vec_extractv4si_0_zext_sse4 was
    first added, this seems reasonable.

    2021-12-18  Roger Sayle  <roger@nextmovesoftware.com>
                Uroš Bizjak  <ubizjak@gmail.com>

    gcc/ChangeLog
            PR target/103611
            * config/i386/i386.md (any_or_plus): New code iterator.
            (define_split): Split (HI<<32)|zext(LO) into piece-wise
            move instructions on !TARGET_64BIT.
            * config/i386/sse.md (*vec_extractv4si_0_zext_sse4):
            Restrict to TARGET_64BIT.

    gcc/testsuite/ChangeLog
            PR target/103611
            * gcc.target/i386/pr103611-2.c: New test case.