https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127382
--- Comment #7 from Hongtao Liu <liuhongt at gcc dot gnu.org> ---
>
> But we also fail to reject this case in vectorizable_conversion which
> only rejects to bit-precision conversion:
For extending integers to a specific bit precision, I believe it should be fine
— there's no specification that requires padded bits to be all zeros or ones,
right?
>
> if (!VECTOR_BOOLEAN_TYPE_P (vectype_out)
> && INTEGRAL_TYPE_P (lhs_type)
> && !type_has_mode_precision_p (lhs_type))
> {
> if (dump_enabled_p ())
> dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
> "type conversion to bit-precision unsupported\n");
> return false;
> }
>
> from bit-precision is OK because all other cases have zero-/sign-extended
> padding. We have to amend this with an explicit BITINT_TYPE check for
> the reverse direction I think.
Similarly, for integer truncation, from bit-precision should be ok.
For others normalization or reject is needed.
Looks like LLVM does additional normalization in the vectorizer instead of
reject
https://godbolt.org/z/s8dsaj3fq
