Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment

[Richard Sandiford <richard.sandiford@arm.com>]

Pan Li via Gcc-patches <gcc-patches@gcc.gnu.org> writes:
> I am not very familiar with the memory pattern, maybe juzhe can provide more information or correct me if anything is misleading.
>
> The different precision try to resolve the below bugs, the second vlm(with different size of load bytes compared to first one)
> is eliminated because vbool8 and vbool16 have the same precision size, aka [8, 8].
>
> vbool8_t v2 = *(vbool8_t*)in;
> vbool16_t v5 = *(vbool16_t*)in;
> *(vbool16_t*)(out + 200) = v5;
> *(vbool8_t*)(out + 100) = v2;
>
> addi    a4,a1,100
> vsetvli a5,zero,e8,m1,ta,ma
> addi    a1,a1,200
> vlm.v   v24,0(a0)
> vsm.v   v24,0(a4)
> // Need one vsetvli and vlm.v for correctness here.
> vsm.v   v24,0(a1)

But I think it's important to think about the patch as more than a way
of fixing the bug above.  The aim has to be to describe the modes as they
really are.

I don't think there's a way for GET_MODE_SIZE to be "conservatively wrong".
A GET_MODE_SIZE that is too small would cause problems.  So would a
GET_MODE_SIZE that is too big.

Like Richard says, I think the question comes down to the amount of padding.
Is it the case that for 4+4X ([4,4]), the memory representation has 4 bits
of padding for even X and 0 bits of padding for odd X?

I agree getting rid of GET_MODE_SIZE and representing everything in bits
would avoid the problem at this point, but I think it would just be pushing
the difficulty elsewhere.  E.g. stack layout will be "interesting" if we
can't work in byte sizes.

Thanks,
Richard