[Bug target/127225] [17 Regression] ICE: in extract_insn, at recog.cc:2894 with -frounding-math -mgeneral-regs-only -mavx512vbmi -mno-sse2

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by hongtao Liu <liuhongt@gcc.gnu.org>:

https://gcc.gnu.org/g:919c0d16c91c930c374db6665f55595653511636

commit r17-4017-g919c0d16c91c930c374db6665f55595653511636
Author: liuhongt <hongtao.liu@intel.com>
Date:   Sun Sep 6 23:10:43 2026 -0700

    i386: Fix unrecognizable V2SF zero move in V4SF vec_init [PR127225]

    With -mno-sse2 -mno-mmx -mno-3dnow, TARGET_SSE is still on but both
    TARGET_MMX and TARGET_MMX_WITH_SSE (TARGET_64BIT && TARGET_SSE2) are
    off, so there is no movv2sf expander even though *vec_concatv2sf_sse
    (TARGET_SSE) can still create V2SFmode pseudos.

    The !TARGET_SSE2 arm of ix86_expand_vector_init_v4sf materialized the
    zero upper half with a raw emit_insn (gen_rtx_SET (...)), which bypasses
    the emit_move_insn_1 fallback of moving via the same-sized integer mode,
    and so left behind

      (set (reg:V2SF 107) (const_vector:V2SF [(const_double:SF 0.0) x2]))

    for extract_insn to choke on.  Use emit_move_insn instead; the zero then
    comes out as a DImode move and the sequence is the xorps/unpcklps/movlhps
    one GCC 16 emitted for this case.

    gcc/ChangeLog:

            PR target/127225
            * config/i386/i386-expand.cc (ix86_expand_vector_init_v4sf): Use
            emit_move_insn rather than a bare SET to materialize the V2SFmode
            zero half, as movv2sf may not be available.

    gcc/testsuite/ChangeLog:

            PR target/127225
            * gcc.target/i386/pr127225.c: New test.