> When the iteration count is unknown, actually compare the costs of
> different VLA modes instead of blindly choosing the bigger LMUL as long
> as there's no unexpected spill. This can prevent some cases when
> -mrvv-max-lmul=dynamic emits worse code than -mrvv-max-lmul=m8, and
> consistent with the current implementation of
> check_vectorise_memory_operation in riscv-string.cc, which chooses the
> smallest possible LMUL, instead of m8 for all cases.
Thinking about it some more, I see what you mean.
It's not really "blindly" right now because -mrvv-max-lmul=dynamic is
supposed to mean "the largest LMUL that doesn't spill" with the
implication that larger LMUL is preferable (1) or neutral (2).
On a typical OOO core with Ovlt (2) holds true and when ignoring
register pressure we could always use the highest LMUL as ops are going
to be cracked into LMUL1 chunks anyway. (1) Is (mostly) true for
chaining uarchs with Ovlt, they really need higher LMUL to perform best.
The main case where the premise doesn't hold is non-Ovlt. But we still
don't want spills so we should always compare costs as long as there's
no clear ceiling like spills ("dynamic") or the type ratio
("conv-dynamic").
But all these are just very rough approximations and don't factor in
e.g. permute latency. It's certainly not easy to get everything mostly
right but I agree on the direction.
BTW: check_vectorise_memory_operation is an exception rather than the
rule, and only works for known lengths. I don't think it would be
controversial to never use a larger LMUL than necessary in riscv-string
(for known lengths of course) and I'd support such a patch.
--
Regards
Robin
