On Thu, Jun 29, 2023 at 11:10 AM Robin Dapp via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
> > Yeah, that part is OK, and was the case I was thinking about when
> > I said OK yesterday. But now that we allow BITSIZE != PRECISION,
> > it's possible for BITSIZE - PRECISION to be more than a full byte,
> > in which case the new loop would not initialise every byte of
> > the mode.
>
> Ah, I see, so when e.g. BITSIZE == 16 and PRECISION == 1. Luckily
> this cannot happen with RVV as all we do is adjust the precision
> of the modes that have BITSIZE == 8. I'm going to add an assert.
> Juzhe would rather work around that in the backend, though.
>
> The other thing I just noticed is
>
> tree
> build_truth_vector_type_for_mode (poly_uint64 nunits, machine_mode mask_mode)
> {
> gcc_assert (mask_mode != BLKmode);
>
> unsigned HOST_WIDE_INT esize;
> if (VECTOR_MODE_P (mask_mode))
> {
> poly_uint64 vsize = GET_MODE_BITSIZE (mask_mode);
> esize = vector_element_size (vsize, nunits);
> }
> else
> esize = 1;
>
> tree bool_type = build_nonstandard_boolean_type (esize);
>
> return make_vector_type (bool_type, nunits, mask_mode);
> }
>
> which gives us wrong precision as we rely on the BITSIZE here as well.
> This results in a precision of 1 for VNx8BI, 2 for VNx4BI and 4 for
> VNx2BI.
This should probably use GET_MODE_PRECISION as well.
OK if it bootstraps/tests on both aarch64 and riscv.
Richard.
>
> Maybe this isn't a problem per se but to me it appears
> just wrong.
>
> Regards
> Robin
>
