[llvm] [VPlan] Handle some VPInstructions in mayReadFromMemory (PR #120058)
Luke Lau via llvm-commits
llvm-commits at lists.llvm.org
Thu Jan 2 20:44:23 PST 2025
================
@@ -115,6 +115,25 @@ bool VPRecipeBase::mayWriteToMemory() const {
bool VPRecipeBase::mayReadFromMemory() const {
switch (getVPDefID()) {
+ case VPInstructionSC:
+ if (Instruction::isBinaryOp(cast<VPInstruction>(this)->getOpcode()))
+ return false;
+ switch (cast<VPInstruction>(this)->getOpcode()) {
+ case Instruction::Or:
+ case Instruction::ICmp:
+ case Instruction::Select:
+ case VPInstruction::AnyOf:
+ case VPInstruction::Not:
+ case VPInstruction::CalculateTripCountMinusVF:
+ case VPInstruction::CanonicalIVIncrementForPart:
+ case VPInstruction::ExtractFromEnd:
+ case VPInstruction::FirstOrderRecurrenceSplice:
+ case VPInstruction::LogicalAnd:
+ case VPInstruction::PtrAdd:
+ return false;
+ default:
+ return true;
+ }
----------------
lukel97 wrote:
Sorry for the delay, I've moved it into VPInstruction now.
> Not sure what you mean with diverging? The VPInstruction version should only mark opcodes as non writing/reading if we are sure they won't access memory
E.g. a non-ordered load is known to not write to memory, so it could return true for `mayReadFromMemory` and false for `mayWriteToMemory`, so two functions wouldn't return the same. But this is just an observation, I'm happy to defer this to later
https://github.com/llvm/llvm-project/pull/120058
More information about the llvm-commits
mailing list