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).
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.
(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 :)
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.
--
Regards
Robin
