Hi Robin
Sorry Kito, that we're having so much back and forth here, it's not my > intention to block anything (not that I could anyway). I just want to > make sure I properly understand the rationale (or the spec, rather). > No worries, it's a great chance to clarify the spec together :) Some time I aso misunderstand the spec...:P > > > Oh, ok, I got the point why you confused on this, the new condition is > > little bit `indirect`, > > it say TARGET_VECTOR_ELEN_64, it would be clear if we TARGET_VECTOR_ELEN > > 32, > > however we don't have that so we test TARGET_VECTOR_ELEN_64 instead of > > TARGET_VECTOR_ELEN > 32, and that will implicitly mean not allow > > zve32x or zve32f > > with any VLEN since we didn't limit/test VLEN here. > > > > In theory that should also test VLEN >= 64 for that, but since we > > already forbit zve32x > > or zve32f which means it at least requires zve64 and it will imply VLEN > >= 64, > > so we don't need to test that. > > Ok, yeah, TARGET_VECTOR_ELEN_64 implies VLEN >= 64. My take is that > TARGET_MIN_VLEN >= 64 is already sufficient as a check and > TARGET_VECTOR_ELEN_64 is too restrictive. My reading of the spec is that > vsetvl ...,e16,mf4 could be allowed for zve32x_zvl64b (or any higher > VLEN/zvl). > Note I'm not talking about mf8 here, that one is settled, just about > e16,mf4 > and e32,mf2. > zve32x_zvl64b will have the same requirement as zve32x_zvl32b, I mean e16,mf4 could be allowed on zve32x_zvl64b, but it also spec conformance if implementation decides to raise an illegal instruction on e16,mf4, which means e16,mf4 is not safe to use on zve32x/zve32f. > (Likewise we don't allow e.g. vsetvl e64,mf4 on v_zvl128b by default but > only > do so starting at v_zvl256b.) > > In the end those cases are very rare and it won't matter much anyway. I'd > just > like to understand if either > (a) it's in the spec and I'm reading it wrong or > (b) we're disabling more than we need to because we don't really mind > (and performance implications are negligible to non-existent anyway) > > You have been hitting those on your uarchs. Is this the attached test > case > with e32,mf2? And exactly the vsetvl ... e32, mf2 faults on an embedded > board > with ELEN = 32 and VLEN = 128? If so then option (a) above is likely :) > Yeah, our core has ELEN = 32 and VLEN >= 128... > > I was hoping we could just disable all mf8 modes by TARGET_VECTOR_ELEN_64 > and > be done with it. > > > I guess I still haven't got the point yet? we didn't touch the > > alignment within this patch, > > so it still requires element alignment for each vector type? > > I mean using MF8 or losing MF8 didn't let us get the capability to do > > misalignment access? > > > > We lose ELLEN=8 MF8 (RVVMF8QI), but we still ELEN=8 MF4 (RVVMF4QI) to > > do those unaligned memory accesses, that should be functional > > equivalence. > > (and both are occupy one vector register, so using MF8 isn't get fewer > > register pressure than MF4) > > Sorry, I was just talking about the spec not about the patch itself. > Please > disregard, I think it's leading us down the wrong alley here. Yes, the > patch > is fine with regards to alignment as it doesn't touch it. > Oh, I read your reply again, yeah...that's really unfortunate about the uselessness of the Zicclsm extension... > > -- > Regards > Robin > >
