https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127382
--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #5)
> (In reply to Hongtao Liu from comment #4)
> > > >
> > > > So TYPE_SIZE equal of @2 and @3 is not enough for _BitInt, need
> > > > TYPE_PRECISION
> > > > for that, I'm working on a patch.
> > >
> > > Also for other INTEGER_TYPEs.
> > regarding conversion, GCC currently vectorizes below testcase directly with
> > padded mode, but for scalar code, there's normalization like (b[i] << 15)
> > >> 15, so the vectorized code looks incorrect and should be restrict to
> > type_has_mode_precision_p?
> >
> > void
> > foo (long *a, _BitInt(17) *b)
> > {
> > for (int i = 0; i != 100; i++)
> > a[i] = b[i];
> > }
>
> Yes, only plain copying can elide normalization. I'm looking into related
> PR127390 at the moment.
>
> We usually handle this by patterns (or for bitfields by if-conversion).
>
> But we also fail to reject this case in vectorizable_conversion which
> only rejects to bit-precision conversion:
>
> 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.
I'm testing a patch for this.
