"Robin Dapp" <rdapp....@gmail.com> writes: >> ...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? > > 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?
It's 1 for VNx16BI, 2 for VNx8BI, and 4 for VNx4BI. There are then respectively 8, 4, and 2 elements per byte. > For our mask modes anything else but zero padding makes no sense, so how > could we clarify this? Generally, we don't try to maintain the value of padding bits. E.g. if we have a single-byte V4BI mode with 4 bits of padding, doing: (set (reg:QI R1) (subreg:QI (reg:V4BI R2) 0)) would not necessarily leave the upper 4 bits of R2 as zero, and so it would not be valid to optimise: (set (reg:QI R1) (and:QI (subreg:QI (reg:V4BI R2) 0) (const_int 15))) to the move above. Similarly, on SVE: (set (reg:VNx8BI R1) (subreg:VNx8BI (reg:VNx4BI R2) 0)) sets Nx4 of the R1 elements to undefined values. The even elements are defined, the odd elements are not. That's why it seems like forcing the padding is masking a bug elsewhere. In general, things should work whatever value the padding bits have. Thanks, Richard
