https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102812
--- Comment #4 from Hongtao.liu <crazylht at gmail dot com> ---
(In reply to Hongyu Wang from comment #3)
> (In reply to Uroš Bizjak from comment #2)
> > Please note that the code above should compile via ix86_expand_vector_set,
> > similar to:
> >
> > --cut here--
> > typedef short v8hi __attribute__((__vector_size__(16)));
> >
> > v8hi foo (short a)
> > {
> > return (v8hi) {a, 0, 0, 0, 0, 0, 0, 0 };
> > }
> > --cut here--
> >
> > that results in:
> >
> > vpxor %xmm0, %xmm0, %xmm0
> > vpinsrw $0, %edi, %xmm0, %xmm0
> > ret
>
> Currently we have
>
> if (TARGET_AVX512FP16 && VALID_AVX512FP16_REG_MODE (mode))
> return true;
>
> in ix86_vector_mode_supported_p, so for SSE2 target V8HFmode would be
> returned in BLKmode.
>
> After I put V8HFmode to VALID_SSE2_REG_MODE the code would be like
>
> vmovss %xmm0, %xmm0, %xmm1
> vpxor %xmm0, %xmm0, %xmm0
> pextrw $0, %xmm1, -10(%rsp)
> vpinsrw $0, -10(%rsp), %xmm0, %xmm0
>
> Seems IRA spills the HF reg to memory..
>
> I wonder whether we should move vector mode support to sse2 for now, as we
> don't have sufficient HF vector arithmetic emulation for non-avx512fp16
> target.
Acccording to document, maybe we can.
@deftypefn {Target Hook} bool TARGET_VECTOR_MODE_SUPPORTED_P (machine_mode
@var{mode})
Define this to return nonzero if the port is prepared to handle
insns involving vector mode @var{mode}. At the very least, it
must have move patterns for this mode.
@end deftypefn