SLP vectorizer ignores slp-max-reg-size

[TocarIP]

I'm trying to limit generation of wide AVX instruction to reduce frequency impact/performance regression.
For the following example (consecutive FP division): https://godbolt.org/z/reP9c78cM I get vector division :vdivpd %ymm0, %ymm1, %ymm0 with 256-bit wide register. I've checked IR and SLP indeed generates %5 = fdiv <4 x double> %2, %4.
When I try to limit register size to 128 I get the same results. Even when building with -mllvm -slp-max-reg-size=1 which should basically remove any slp vectorization completely. Wide AVX is know to cause significant performance regression from reduced frequency on some CPUs (especially older ones)

[alexey-bataev]

SLP vectorizer may generate long vectors, even if -slp-max-reg-size is specified. It relies on the codegen ability of long vectors splitting. -slp-max-reg-size does not limit the size of vector, but the size of vector registers. The vector itself still may span across several vector registers.

[TocarIP]

Sorry, I didn't see the notification about the replay. Is there any way to limit the length of vector register to 128 (similar to mprefer-vector-width=128)?

[alexey-bataev]

No such options or they do not guarantee anything. Use proper march tuning

[TocarIP]

What do you mean by proper march tuning, just disabling every simd instruction from the last ~12 years, or is there tuning feature controlling this?

[alexey-bataev]

Use march that supports avx2 to enable only 256bit registers

[TocarIP]

I'm not sure I understand, avx2 would enable both new 128-bit instructions (good) and their 256-bit versions (bad). This is a current situation that I'm trying to avoid (application regresses when built with march=haswell due to frequency drop). LLVM already has flags to change this (mprefer-vector-width), but slp ignores it.

[alexey-bataev]

This option is for codegen, not for the vectorizer. Vectorizer generates long vectors, codegen should split them properly, based on march and mprefer-vector-width. Looks like codegen issue.

[TocarIP]

That makes sense, thank you!. FWIW backend uses the flag inside getRegisterBitWidth (at least on x86) and Loop vectorizer determines VF as getRegisterBitWidth/widest type (in

llvm-project/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp

Line 4295 in 8e9fda1

const TypeSize WidestRegister = TTI.getRegisterBitWidth(

), which looks like it doesn't depend on backend splitting wide vectors.

[alexey-bataev]

Loop vectorizer works a bit differently (fixed length lv). Scalable lv works in more "slpish" way. SLP vectorizer works more in vector length agnostic way, relying completely on backend for splitting long vectors. Consider them as the abstract representation, SLP tries to be as more target agnostic as possible. Most of SLP options are for the debugging only and they do not guarantee codegen results at all.