https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127382
--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Hongtao Liu from comment #8) > > 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. Indeed, but if vectorizer already asks the backend whether it is bitint_ext_partial or full, it can also at the same time for partial double check if there are any padding bits or not (or simplify it by just checking if the mode precision of the mode is >= then the precision of the BITINT_TYPE. For bitint_ext_undef, the vectorizer can just sign or zero extend it manually before use by 2 shifts or bitwise and. And similarly for stores, although in that case it needs to sign or zero extend for extend other than bitint_ext_undef.
