-
Notifications
You must be signed in to change notification settings - Fork 14.3k
[VPlan] Remove overlapping VPInstruction::mayWriteToMemory. NFCI #120039
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
[VPlan] Remove overlapping VPInstruction::mayWriteToMemory. NFCI #120039
Conversation
VPInstruction has a definition of mayWriteToMemory, which seems to only be used by VPlanSLP. However VPInstructions are already handled in VPRecipeBase::mayWriteToMemory, and everywhere else seems to use this definition. I think these should be the same for all intents and purposes. The VPRecipeBase definition is more conservative but returns true for stores/calls/invokes/SLPStores.
@llvm/pr-subscribers-vectorizers Author: Luke Lau (lukel97) ChangesVPInstruction has a definition of mayWriteToMemory, which seems to only be used by VPlanSLP. However VPInstructions are already handled in VPRecipeBase::mayWriteToMemory, and everywhere else seems to use this definition. I think these should be the same for all intents and purposes. The VPRecipeBase definition is more conservative but returns true for stores/calls/invokes/SLPStores. Full diff: https://github.com/llvm/llvm-project/pull/120039.diff 2 Files Affected:
diff --git a/llvm/lib/Transforms/Vectorize/VPlan.h b/llvm/lib/Transforms/Vectorize/VPlan.h
index e8902009455ef4..ad1e56c6ef82ec 100644
--- a/llvm/lib/Transforms/Vectorize/VPlan.h
+++ b/llvm/lib/Transforms/Vectorize/VPlan.h
@@ -1347,14 +1347,6 @@ class VPInstruction : public VPRecipeWithIRFlags,
LLVM_DUMP_METHOD void dump() const;
#endif
- /// Return true if this instruction may modify memory.
- bool mayWriteToMemory() const {
- // TODO: we can use attributes of the called function to rule out memory
- // modifications.
- return Opcode == Instruction::Store || Opcode == Instruction::Call ||
- Opcode == Instruction::Invoke || Opcode == SLPStore;
- }
-
bool hasResult() const {
// CallInst may or may not have a result, depending on the called function.
// Conservatively return calls have results for now.
diff --git a/llvm/lib/Transforms/Vectorize/VPlanRecipes.cpp b/llvm/lib/Transforms/Vectorize/VPlanRecipes.cpp
index 4836186525fd6a..92b534b6776367 100644
--- a/llvm/lib/Transforms/Vectorize/VPlanRecipes.cpp
+++ b/llvm/lib/Transforms/Vectorize/VPlanRecipes.cpp
@@ -67,6 +67,8 @@ bool VPRecipeBase::mayWriteToMemory() const {
case VPInstruction::PtrAdd:
return false;
default:
+ // TODO: for calls, we can use attributes of the called function to rule
+ // out memory modifications.
return true;
}
case VPInterleaveSC:
|
@llvm/pr-subscribers-llvm-transforms Author: Luke Lau (lukel97) ChangesVPInstruction has a definition of mayWriteToMemory, which seems to only be used by VPlanSLP. However VPInstructions are already handled in VPRecipeBase::mayWriteToMemory, and everywhere else seems to use this definition. I think these should be the same for all intents and purposes. The VPRecipeBase definition is more conservative but returns true for stores/calls/invokes/SLPStores. Full diff: https://github.com/llvm/llvm-project/pull/120039.diff 2 Files Affected:
diff --git a/llvm/lib/Transforms/Vectorize/VPlan.h b/llvm/lib/Transforms/Vectorize/VPlan.h
index e8902009455ef4..ad1e56c6ef82ec 100644
--- a/llvm/lib/Transforms/Vectorize/VPlan.h
+++ b/llvm/lib/Transforms/Vectorize/VPlan.h
@@ -1347,14 +1347,6 @@ class VPInstruction : public VPRecipeWithIRFlags,
LLVM_DUMP_METHOD void dump() const;
#endif
- /// Return true if this instruction may modify memory.
- bool mayWriteToMemory() const {
- // TODO: we can use attributes of the called function to rule out memory
- // modifications.
- return Opcode == Instruction::Store || Opcode == Instruction::Call ||
- Opcode == Instruction::Invoke || Opcode == SLPStore;
- }
-
bool hasResult() const {
// CallInst may or may not have a result, depending on the called function.
// Conservatively return calls have results for now.
diff --git a/llvm/lib/Transforms/Vectorize/VPlanRecipes.cpp b/llvm/lib/Transforms/Vectorize/VPlanRecipes.cpp
index 4836186525fd6a..92b534b6776367 100644
--- a/llvm/lib/Transforms/Vectorize/VPlanRecipes.cpp
+++ b/llvm/lib/Transforms/Vectorize/VPlanRecipes.cpp
@@ -67,6 +67,8 @@ bool VPRecipeBase::mayWriteToMemory() const {
case VPInstruction::PtrAdd:
return false;
default:
+ // TODO: for calls, we can use attributes of the called function to rule
+ // out memory modifications.
return true;
}
case VPInterleaveSC:
|
// TODO: for calls, we can use attributes of the called function to rule | ||
// out memory modifications. |
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.
This is not really relevant, there won't be any calls there
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.
Thanks, I've removed the TODO
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.
LGTM, thanks
VPInstruction has a definition of mayWriteToMemory, which seems to only be used by VPlanSLP. However VPInstructions are already handled in VPRecipeBase::mayWriteToMemory, and everywhere else seems to use this definition. I think these should be the same for all intents and purposes. The VPRecipeBase definition is more conservative but returns true for stores/calls/invokes/SLPStores.