[Bug c++/10566] simple, but big problem

[Bug c++/10566] simple, but big problem

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 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:37e4e7f77d8f7b7e911bf611a0f8edbc3a850c7a

commit r13-961-g37e4e7f77d8f7b7e911bf611a0f8edbc3a850c7a
Author: Roger Sayle <roger@nextmovesoftware.com>
Date:   Thu Jun 2 18:46:37 2022 +0100

    PR target/105791: Add V1TI to V_128_256 for xop_pcmov_v1ti on x86_64.

    This patch resolves PR target/105791 which is a regression that was
    accidentally introduced for my workaround to PR tree-optimization/10566.
    (a deeper problem in GCC's vectorizer creating VEC_COND_EXPR when it
    shouldn't).  The latest issues is that by providing a vcond_mask_v1tiv1ti
    pattern in sse.md, the backend now calls ix86_expand_sse_movcc with
    V1TImode operands, which has a special case for TARGET_XOP to generate
    a vpcmov instruction.  Unfortunately, there wasn't previously a V1TImode
    variant, xop_pcmov_v1ti, so we'd ICE.

    This is easily fixed by adding V1TImode (and V2TImode) to V_128_256
    which is only used for defining XOP's vpcmov instruction.  This in turn
    requires V1TI (and V2TI) to be supported by <avxsizesuffix> (though
    the use if <avxsizesuffix> in the names xop_pcmov_<mode><avxsizesuffix>
    seems unnecessary; the mode makes the name unique).

    2022-06-02  Roger Sayle  <roger@nextmovesoftware.com>

    gcc/ChangeLog
            PR target/105791
            * config/i386/sse.md (V_128_256):Add V1TI and V2TI.
            (define_mode_attr avxsizesuffix): Add support for V1TI and V2TI.

    gcc/testsuite/ChangeLog
            PR target/105791
            * gcc.target/i386/pr105791.c: New test case.