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.
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.
--
Regards
Robin
