> 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. > > This patch used to be a part of the m1-dynamic patch I proposed earlier, > but as this can be justified independently, I split this out. > > As I changed the `else if` branch to an independent if-clause, it can > now affect both dynamic and conv-dynamic. I am not quite sure but I > guess avoiding a VLS loop for unknown niter cases would be reasonable as > well for conv-dynamic when neither is preferred by the conv-dynamic > heuristics. > > When running the regression tests, I found several testcases, including > vec_sat_u_sub_zip.c, contain multiline DejaGnu directives that are not > supported by the DejaGnu framework. I plan to fix them in a separate > testsuite-only patch.
Regarding the earlier m1-dynamic part: We tried a PoC implementation of the M1-epilogue scheme (M8/M4 length-controlled main loop + M1 length-controlled epilogue), but it turned out that most SPEC CPU 2017 cases did not show any performance improvement on our internal uarch, some even regressing, showing that the performance impact of length checks can be huge. Actually we still would prefer adding that -mrvv-max-lmul=m1-dynamic option, or something similar, to have different maximal LMUL choices for length-controlled vectorization and non-length-controlled scenarios (e.g. M1 for length-controlled, and dynamic otherwise). This way vendors with non-Ovlt uarchs can then use these options to find out what would be the best balanced choice for their processors and benchmarks, without changing the default behavior of GCC. Bohan
