On Mon, Mar 24, 2025 at 6:53 PM Robin Dapp <rdapp....@gmail.com> wrote: > > Hi Kito, > > > So valid range fractional LMUL for SEW=8, 16 32 are: > > > > mf8 = [8, (1/8)*32] = [8, 4] = [], no SEW is valid with mf8 for ELEN = 32 > > mf4 = [8, (1/4)*32] = [8, 8] = only SEW 8 with mf4 is valid > > mf2 = [8, (1/2)*32] = [8, 16] = SEW 8 and 16 with mf2 are valid > > > > [1] > > https://github.com/riscvarchive/riscv-v-spec/blob/master/v-spec.adoc#342-vector-register-grouping-vlmul20 > > Yes, so AFAIK we currently prohibit SEW/LMUL combinations/modes that would > lead > to sub-element modes but we don't prevent MF8 for ELEN = 32 entirely. > > Isn't the issue here that an ELEN = 32 but VLEN 32 implementation could decide > to not to implement MF8 at all (even if it didn't lead to issues with the > proper VLEN) so we must not use it?
This does not only happen on ELEN=32 and VLEN=32, it happened on all ELEN=32 arch, and one of our internal configurations hit this... > That's unfortunate but in line with other > IMHO unfortunate spec decisions like unaligned vector access so there's no way > around it. I didn't get the point around the unaligned vector stuff? Do you mean the access does not align to VLEN or something else, do you mind giving a few examples? > What's the plan for this patch now? As I mentioned before, our internal configuration hit this issue, so our goal is to include this for GCC 15, also I think this also does not affect all other targets with zve64* and v, so this should be pretty safe changes I think. (I mean won't affect almost all other people/core.) > > > I am not sure I got the point, we are using early clobber to avoid the > > overlap constraint, that's pretty conservative way and should not lead > > the problem here when we using LMUL=1/SEW=32 for V2SI, or are you > > worry about we may put two V2SI within single vector register? > > Hmm, yeah I don't remember what I was thinking here. It should be ok to use > LMUL = 1, right. What I don't see is the connection to the issue the patch is > addressing, though. I would expect a test that ensures we're not emitting an > mf8 vsetvl. Yeah, that sounds reasonable, will add a testcase in v3 > > -- > Regards > Robin >
