https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127382
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
(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.
