Ok, so whenever we didn't split a vector into LMUL1-sized (128 here) chunks
in
the first place we cannot go back to LMUL1 any more.
Doesn't that also mean that _if_ we split into 128-bit chunks (first case
above) running on VLEN=256 would look like
v8 = [0, 1, 2, 3, ?, ?, ?, ?]
v9 = [4, 5, 6, 7, ?, ?, ?, ?]
Then the ABI is incompatible between -mrvv-max-lmul=m1 and -mrvv-max-lmul=m2?
Also incompatible with LLVM.
Yes, that was kind of my point. So let's spell it out:
For CC/ABI reasons a
typedef int32_t int32x8_t __attribute__ ((vector_size (32)));
on VLEN=128 _must_ use LMUL2, no way around it (except spilling).
Therefore we must ignore -mrvv-max-lmul for it. We also shouldn't allow
restricting LMUL for "GCC vectors" at all.
All other options would restrict the calling convention to the same VLEN (I
wasn't aware "min-VLEN" was a CC design goal, I must have missed it when it
was last discussed) as well as the same LMUL.
That would indicate that we need something like your original patch where
vls_mode_valid_p just restricts auto-vec/get_vector_mode. Not that I like it
but given the discussion it seems inevitable.
--
Regards
Robin
