https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127225
--- Comment #3 from Hongtao Liu <liuhongt at gcc dot gnu.org> ---
For mgenerally-regs-only, looks like it's partly overrided by following
-mavx512vbmi in the command line, the actual option list is equal to
-frounding-math -mavx512vbmi -mno-sse2 -mno-mmx -mno-3dnow which also triggered
ICE.
The non-SSE2 arm of ix86_expand_vector_init_v4sf, added in 45c9868f1b2 (PR
target/126619, GCC 17 only — 14/15/16 are clean),
materialized the zero half with a raw emit_insn (gen_rtx_SET (...)), which
bypasses emit_move_insn_1's fallback of moving via
the same-size integer mode. Hence the unrecognizable (set (reg:V2SF)
(const_vector:V2SF [0.0 x2])).
+++ b/gcc/config/i386/i386-expand.cc
@@ -19554,7 +19554,10 @@ ix86_expand_vector_init_v4sf (rtx target, rtx *ops)
rtx tmp1 = gen_reg_rtx (V2SFmode);
ix86_expand_vector_init_concat (V2SFmode, tmp1, ops, 2);
rtx tmp2 = gen_reg_rtx (V2SFmode);
- emit_insn (gen_rtx_SET (tmp2, CONST0_RTX (V2SFmode)));
+ /* Without both MMX and TARGET_MMX_WITH_SSE there's no movv2sf,
+ go through emit_move_insn so the zero can be materialized in
+ the corresponding integer mode. */
+ emit_move_insn (tmp2, CONST0_RTX (V2SFmode));
rtx tmp = gen_rtx_VEC_CONCAT (V4SFmode, tmp1, tmp2);
