> 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.
But shouldn't the branches be very easy to predict and regular VLS-with-epilogue loops work fine on other archs? Can you tell more about where the regression happens? What does your PoC do, and how does its codegen differ from what you want? My idea was to use no length control for the main loop (because small lengths degrade performance). > > 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. As discussed, this is IMHO a vectorizer topic and we cannot solve it in the backend in and adequate way. I have it on my list for the vectorizer, though, and I don't think it's too involved. -- Regards Robin
