https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103571
--- Comment #10 from Hongtao.liu <crazylht at gmail dot com> --- (In reply to Uroš Bizjak from comment #9) > (In reply to Hongtao.liu from comment #8) > > (In reply to Uroš Bizjak from comment #6) > > > (In reply to Hongtao.liu from comment #5) > > > > > > > There're several places in i386-expand.c which assume TARGET_AVX512FP16 > > > > for > > > > case V8HF/V16HF/V32HF, if we want to put V8HF/V16HF/V32HF in > > > > VALID_SSE2/AVX256/AVX512F_REG_MODE, we need to "fix" them first. > > > > > > These are of the type: > > > > > > use_vector_set = TARGET_AVX512FP16 && one_var == 0; > > > gen_vec_set_0 = gen_vec_setv8hf_0; > > > > > > So they look immune to the above change. > > > > This is ok. > > > > I mean in ix86_expand_vector_init_duplicate > > > > case E_V8HFmode: > > case E_V16HFmode: > > case E_V32HFmode: > > return ix86_vector_duplicate_value (mode, target, val); > > > > AVX2 is needed for V8HF/V16HFmode vpbroadcastw, AVX512BW is needed for > > V32HFmode, those modes should be handled same as V8HI/V16HI/V32HImode. > > > > Also in ix86_expand_vector_extract, below should be under TARGET_AVX512BW, > > other wise, vector_extract go through stack. > > > > case E_V32HFmode: > > tmp = gen_reg_rtx (V16HFmode); > > if (elt < 16) > > emit_insn (gen_vec_extract_lo_v32hf (tmp, vec)); > > else > > emit_insn (gen_vec_extract_hi_v32hf (tmp, vec)); > > ix86_expand_vector_extract (false, target, tmp, elt & 15); > > return; > > > > > > others seems to be ok. > > Please note that the change mainly affects moves between SSE and GP > registers. Expansion is done way before register allocation, and if we allow > these modes earlier, I'm not sure I understand how it affects expand. > > I propose we proceed with my patch and fix eventual fallout as a follow-up. Sure.