On Mon, Mar 24, 2025 at 11:35 PM Robin Dapp <rdapp....@gmail.com> wrote: > > > 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... > > Wait, is there something I keep missing? There must be I guess. > > Disregarding the SEW=8 case because that one is clear, but take for example: > > ENTRY (RVVMF4HI, TARGET_MIN_VLEN > 32 && !TARGET_XTHEADVECTOR, LMUL_F4, 64) > > that the patch changes to > > ENTRY (RVVMF4HI, TARGET_VECTOR_ELEN_64 && !TARGET_XTHEADVECTOR, LMUL_F4, 64) > > My reading of the spec is that we are allowed to emit instructions with that > mode for ELEN = 32 and VLEN = 64 but not for ELEN = 32 and VLEN = 32. To me > that is in the same vein as when emitting RVVMF4SI for VLEN >= 128 even though > RVVMF4SI is not permissible by default (i.e. VLEN = 64). If that's incorrect > then please let me know.
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. NOTE: RVVMF4HI is OK for VLEN=64 since 64 * 1/4 = 16 = able to hold one HI, and you say SI in your reply I assume that is a typo? > >> 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? > > I meant the general situation with not making vector misalignment required > (i.e. non faulting) in the spec. I realize that this has been a tradeoff for > embedded-oriented vector implementations but it's annoying from a compiler's > perspective to not be able to emit them in a default march. Similar here but > surely not as important for performance: I would have liked us to be able to > emit MF8 regardless of ELEN and just avoid the modes where it doesn't make > sense. 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) > > -- > Regards > Robin >
