[PATCH] D92059: [SLP] Control maximum vectorization factor from TTI
Stanislav Mekhanoshin via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Nov 24 14:33:37 PST 2020
rampitec created this revision.
rampitec added reviewers: jonpa, arsenm, spatel, ABataev, vdmitrie.
Herald added subscribers: kerbowa, pengfei, hiraditya, tpr, nhaehnle, jvesely.
Herald added a project: LLVM.
rampitec requested review of this revision.
Herald added a subscriber: wdng.
D82227 <https://reviews.llvm.org/D82227> has added a proper check to limit PHI vectorization to the
maximum vector register size. That unfortunately resulted in at
least a couple of regressions on SystemZ and x86.
This change reverts PHI handling from D82227 <https://reviews.llvm.org/D82227> and replaces it with
a more general check in SLPVectorizerPass::tryToVectorizeList().
Moved to tryToVectorizeList() it allows to restart vectorization
if initial chunk fails.
However, this function is more general and handles not only PHI
but everything which SLP handles. If vectorization factor would
be limited to maximum vector register size it would limit much
more vectorization than before leading to further regressions.
Therefore a new TTI callback getMaximumVF() is added with the
default 0 to preserve current behavior and limit nothing. Then
targets can decide what is better for them.
The callback gets ElementSize just like a similar getMinimumVF()
function and the main opcode of the chain. The latter is to avoid
regressions at least on the AMDGPU. We can have loads and stores
up to 128 bit wide, and <2 x 16> bit vector math on some
subtargets, where the rest shall not be vectorized. I.e. we need
to differentiate based on the element size and operation itself.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 20380 bytes
Desc: not available
More information about the llvm-commits