https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127382
--- Comment #8 from Hongtao Liu <liuhongt at gcc dot gnu.org> ---
(In reply to Hongtao Liu from comment #7)
> >
> > 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
Hmm, for target with bitint_ext_full , the vectorization should be ok since
padding is guaranteed sign/zero extended,
for target with bitint_ext_undef the normalization is needed.
For target with bitint_ext_partial, vectorization is probabaly ok since the big
integer like _BitInt (129) won't be vectorized, and small integer behaves same
as bitint_ext_full.
