-
Notifications
You must be signed in to change notification settings - Fork 10.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SLP] Exit early if MaxVF < MinVF (NFCI). #83283
Conversation
Exit early if MaxVF < MinVF. In that case, the loop body below will never get entered. Note that this adjusts the condition from MaxVF <= MinVF. If MaxVF == MinVF, vectorization may still be feasible (and the loop below gets entered).
@llvm/pr-subscribers-llvm-transforms Author: Florian Hahn (fhahn) ChangesExit early if MaxVF < MinVF. In that case, the loop body below will never get entered. Note that this adjusts the condition from MaxVF <= MinVF. If MaxVF == MinVF, vectorization may still be feasible (and the loop below gets entered). Full diff: https://github.com/llvm/llvm-project/pull/83283.diff 1 Files Affected:
diff --git a/llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp b/llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
index 2b7d518c1c1a78..e381cd2c5794b1 100644
--- a/llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
+++ b/llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
@@ -13912,10 +13912,11 @@ bool SLPVectorizerPass::vectorizeStores(ArrayRef<StoreInst *> Stores,
unsigned MinVF = TTI->getStoreMinimumVF(
R.getMinVF(DL->getTypeSizeInBits(ValueTy)), StoreTy, ValueTy);
- if (MaxVF <= MinVF) {
+ if (MaxVF < MinVF) {
LLVM_DEBUG(dbgs() << "SLP: Vectorization infeasible as MaxVF (" << MaxVF
<< ") <= "
<< "MinVF (" << MinVF << ")\n");
+ return;
}
// FIXME: Is division-by-2 the correct step? Should we assert that the
|
@@ -13912,10 +13912,11 @@ bool SLPVectorizerPass::vectorizeStores(ArrayRef<StoreInst *> Stores, | |||
unsigned MinVF = TTI->getStoreMinimumVF( | |||
R.getMinVF(DL->getTypeSizeInBits(ValueTy)), StoreTy, ValueTy); | |||
|
|||
if (MaxVF <= MinVF) { | |||
if (MaxVF < MinVF) { | |||
LLVM_DEBUG(dbgs() << "SLP: Vectorization infeasible as MaxVF (" << MaxVF | |||
<< ") <= " |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
<=
-> <
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be fixed, thanks!
Hmm, I don't think this is NFC, would be good to have a test |
Yes I think technically this could change dbg output. Let me add a test for that. |
Not a debug, I think it may change vectorization output |
Ah yes, I missed the updates in the outer loop. I tried to find a test case where the return changes behavior, but wasn't able to do so on X86/AArch64 in MultiSource/SPEC and a set of internal benchmarks. But I updated the PR to use |
✅ With the latest revision this PR passed the C/C++ code formatter. |
// Capturing structured bindings are a C++ 20 extension, so use a separate | ||
// variable for now. | ||
auto &DataVar = Data; | ||
auto E = make_scope_exit([&]() { | ||
Operands.clear(); | ||
Operands.push_back(Stores[Data.first]); | ||
PrevDist = Data.second; | ||
Operands.push_back(Stores[DataVar.first]); | ||
PrevDist = DataVar.second; | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Better to make it in a separate NFC patch.
@@ -13912,10 +13918,11 @@ bool SLPVectorizerPass::vectorizeStores(ArrayRef<StoreInst *> Stores, | |||
unsigned MinVF = TTI->getStoreMinimumVF( | |||
R.getMinVF(DL->getTypeSizeInBits(ValueTy)), StoreTy, ValueTy); | |||
|
|||
if (MaxVF <= MinVF) { | |||
if (MaxVF < MinVF) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean this change increases cases, where the vectorization may be triggered, since you're loosening the restriction. So need to add the test for such a case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I might be missing something here. The original code only guarded the debug output by this check AFAICT, but always also reached the for loop below, which would not be entered if MaxVF < MinVF
.
Now the code continues early instead of reaching the for loop, so it should only restrict the cases where we execute the loop below (and could vectorize)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, Yes, missed there were continue before.
Use ScopeExit to make sure Operands/PrevDist are updated on all paths in the loop. This makes it easier to ensure they are updated correctly if new early continues are added. Split off from llvm#83283
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LG
Exit early if MaxVF < MinVF. In that case, the loop body below will never get entered. Note that this adjusts the condition from MaxVF <= MinVF. If MaxVF == MinVF, vectorization may still be feasible (and the loop below gets entered).