[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