[SLP] SLP ignores command line options and creates oversized vectors

[ashermancinelli]

The SLP vectorizer is creating vectors that exceed the maximum register size specified by -slp-max-reg-size, the "prefer-vector-width"="N" metadata, and the -force-vector-width=N command line option.

https://godbolt.org/z/KMj67594P

I see a few checks like this in SLPVectorizer.cpp

// Lines 1804-1809
if (MaxVectorRegSizeOption.getNumOccurrences())
  MaxVecRegSize = MaxVectorRegSizeOption;
else
  MaxVecRegSize = 
    TTI->getRegisterBitWidth(TargetTransformInfo::RGK_FixedWidthVector)
        .getFixedValue();

// Line 2072
unsigned getMaximumVF(unsigned ElemWidth, unsigned Opcode) const {
  unsigned MaxVF = MaxVFOption.getNumOccurrences() ?
    MaxVFOption : TTI->getMaximumVF(ElemWidth, Opcode);
  return MaxVF ? MaxVF : UINT_MAX;
}

Is this expected behavior? Is there another way to force slp to use a given max vector width?

[alexey-bataev]

See #110749

But I have a plan which may improve it in future by introducing "forest" vectorization

[ashermancinelli]

Thanks! So it may be improved soon, and also:

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.

Should I tag this as a codegen issue then?

[alexey-bataev]

Thanks! So it may be improved soon, and also:

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.

Should I tag this as a codegen issue then?

Unless it causes issue in the backend, no. As I explained in the previous thread, it is natural for SLP to generate wide vectors, all these -slp options do not guarantee anything, you should not rely on them, they are intended for the development and debugging

[ashermancinelli]

How can we allow the use of arch-specific intrinsics and inline assembly while preventing wider vectors from being generated by vectorization? IIUC, disabling the arch tuning flags means user-written intrinsics and inline assembly will not make it to the generated assembly, but we have no other ways to force llvm to legalize vectors down to the size we want.

[alexey-bataev]

How can we allow the use of arch-specific intrinsics and inline assembly while preventing wider vectors from being generated by vectorization? IIUC, disabling the arch tuning flags means user-written intrinsics and inline assembly will not make it to the generated assembly, but we have no other ways to force llvm to legalize vectors down to the size we want.

SLP is target-independent and is not intended to be used with target-dependent instrinsics or assembly directly. It relies completely on the backend regarding proper wide vector splitting

[ashermancinelli]

Your point that SLP should not need to concern itself with target-specific intrinsics is well-taken, but if we (for example) use avx512 intrinsics on a skylake machine and want to disable 512b vectors generated by LLVM, disabling 512b vecs in the target flags will cause avx512 instrinsics to error out (godbolt).

@dzaima made the point on discord that the intrinsics will look like regular operations to isel, and it has no way to distinguish between target-specific intrinsics and instructions created by SLP/LV. IIUC, this means the only possible place to handle preferred vector widths is the pass that introduces the vectors.

[alexey-bataev]

Your point that SLP should not need to concern itself with target-specific intrinsics is well-taken, but if we (for example) use avx512 intrinsics on a skylake machine and want to disable 512b vectors generated by LLVM, disabling 512b vecs in the target flags will cause avx512 instrinsics to error out (godbolt).

These errors are not related to SLP

@dzaima made the point on discord that the intrinsics will look like regular operations to isel, and it has no way to distinguish between target-specific intrinsics and instructions created by SLP/LV. IIUC, this means the only possible place to handle preferred vector widths is the pass that introduces the vectors.

No, that's a wrong assumption. The backend(codegen) should handle it. All vectorizers are target-independent and rely on the backend, if it comes to splitting the long vectors

[ashermancinelli]

Is there a way we can distinguish vectors produced by SLP from other vectors/vector instructions in the IR?

The only way to support this use case that I can think of is to duplicate some of SelectionDAG's legalization logic in a post-SLP legalization pass that legalizes only the vectors produced by SLP into the user's preferred vector width. I don't like this, but can you think of another way for us to accommodate SLP not recognizing the perfer-vector-width metadata?

[alexey-bataev]

Is there a way we can distinguish vectors produced by SLP from other vectors/vector instructions in the IR?

The only way to support this use case that I can think of is to duplicate some of SelectionDAG's legalization logic in a post-SLP legalization pass that legalizes only the vectors produced by SLP into the user's preferred vector width. I don't like this, but can you think of another way for us to accommodate SLP not recognizing the perfer-vector-width metadata?

I don't understand why do you need it

[dzaima]

fwiw, I believe this is the thread I was remembering: #68311 (that specific issue demonstrating LLVM unexpectedly chopping an explicit 512-bit AVX-512 intrinsic into multiple 256-bit ones due to an optimization pass converting the 512-bit load/store IR instructions into a memcpy which can't keep the explicit width)

[ashermancinelli]

On skylake-avx512 for example, user-written avx512 instructions ought to persist to the assembly but I don't want LLVM to itself to create vectors >256 bits. This means I cannot disable avx512 -mno-avx512f, else the intrinsics will not make it to the assembly since ISel has no way of knowing which instructions came from the source and which came from LLVM. Setting -mprefer-vector-width=256 prevents LoopVectorize from creating >256b vectors, but SLP continues to create 512/1024b vectors, and as you say there is no way to prevent SLP from creating vectors >256b. I do not see how to resolve this conflict.

[alexey-bataev]

Currently, there is no way of doing this. But, as I said before, I plan to implement forest vectorization, which, I think, may fix this issue as a side effect

[ashermancinelli]

Okay, thank you!