"juzhe.zh...@rivai.ai" <juzhe.zh...@rivai.ai> writes: >>> What's the byte size of VNx1BI, expressed as a function of N? >>> If it's CEIL (N, 8) then we don't have a way of representing that yet. > N is a poly value. > RVV like SVE support scalable vector. > the N is poly (1,1). > > VNx1B mode nunits = poly(1,1) units. > VNx1B mode bitsize =poly (1,1) bitsize. > VNx1B mode bytesize = poly(1,1) units (currently). Ideally and more accurate, > it should be VNx1B mode bytesize =poly (1/8,1/8).
But this would be a fractional bytesize, and like Richard says, the memory subsystem would always access full bytes. So I think the bytesize would have to be at least CEIL (N, 8). > However, it can't represent it like this. GCC consider its bytesize as poly > (1,1) bytesize. Ah, OK. That (making the size N bytes) does seem like a reasonable workaround, provided that it matches the C types, etc. So the total amount of padding is 7N bits (I assume at the msb of the type when viewed as an integer). I agree that what (IIUC) was discussed upthread works, i.e.: bytesize = N bitsize = N * 8 (fixed function of bytesize) precision = N nunits = N unit_size = 1 unit_precision = 1 But target-independent code won't expect this layout, so supporting it will involve more than just adjusting the parameters. Thanks, Richard
