> Am 25.11.2024 um 15:36 schrieb Robin Dapp <rdapp....@gmail.com>:
>
>
>>
>> ...it's not clear to me that we should define the upper bits of the
>> byte to be zero. What would rely on that? Is it something that we'd
>> require for all loads and stores of such modes?
Btw, we’ve been there on the tree level with native encode/interpret as well.
Also with
Uses of masks where we ended up with explicit masking before uses instead.
Richard
> Yes, I meant fewer than BITS_PER_UNIT bits in total. As opposed to SVE's
> "balanced" mask representation in riscv's case the bits are packed at the
> beginning.
>
> Loads and stores of masks only operate on the bits the mask actually
> contains so when we e.g. have four vector units/elements only four
> mask bits are loaded or stored.
>
> The mode size of those very small modes is still one byte, i.e. we have
> padding for them. But this only matters for the internal representation
> of those modes (and has been the source of several issues already of
> course, the masked else being one of them I believe).
>
> How does encoding work for SVE's small mask modes? I suppose
>
> unsigned int elt_bits = vector_element_size (GET_MODE_PRECISION (mode),
> GET_MODE_NUNITS (mode));
>
> is != 1 but rather adjusted so a byte is filled?
>
> For our mask modes anything else but zero padding makes no sense, so how
> could we clarify this?
