https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122382
--- Comment #5 from Hongtao Liu <liuhongt at gcc dot gnu.org> ---
(In reply to Oleksandr Kulkov from comment #4)
> Retested with GCC 17.0.0 20261023
> (7ae37a76b3274e8adf0a15171008d4eb89910535), after the PR121688 changes. The
> original eight-element example now uses packed F16C at -O3, but only after
> unrolling and SLP; the loop vectorizer still rejects it. At -O2 it remains
> scalar.
Because loop vectorizer by default requires same vector length(x86 backend
doesn't define TARGET_VECTORIZE_RELATED_MODE, I have tried to define it with
same VF but failed several years ago, there're many places with implicit
assumption of same vector length) and replies on vec_pack_trunk_vnsf and
vec_unpacks_{lo,hi}_vnhf. The changes in PR121688 only extend optab
trunc/extendmn2 with F16C, but vec_pack/unpacks related patterns are still with
TARGET_AVX512FP16.
