CodeGen: More accurate mayAlias for instructions with multiple MMOs

[nhaehnle]

There can only be meaningful aliasing between the memory accesses of
different instructions if at least one of the accesses modifies memory.

This check is applied at the instruction-level earlier in the method.
This change merely extends the check on a per-MMO basis.

This affects a SystemZ test because PFD instructions are both mayLoad
and mayStore but may carry a load-only MMO which is now no longer
treated as aliasing loads. The PFD instructions are from llvm.prefetch
generated by loop-data-prefetch.

---

Stack:

• [3/3] CodeGen/AMDGPU: Allow 3-address conversion of bundled instructions #166213
• [2/3] CodeGen: Handle bundled instructions in two-address-instructions pass #166212
• [1/3] CodeGen: More accurate mayAlias for instructions with multiple MMOs #166211 ⬅

⚠️ Part of a stack created by spr. Merging this PR using the GitHub UI may have unexpected results.

[llvmbot]

@llvm/pr-subscribers-backend-systemz

Author: Nicolai Hähnle (nhaehnle)

Changes

There can only be meaningful aliasing between the memory accesses of
different instructions if at least one of the accesses modifies memory.

This check is applied at the instruction-level earlier in the method.
This change merely extends the check on a per-MMO basis.

This affects a SystemZ test because PFD instructions are both mayLoad
and mayStore but may carry a load-only MMO which is now no longer
treated as aliasing loads. The PFD instructions are from llvm.prefetch
generated by loop-data-prefetch.

---

Stack:

• [5/5] #166213
• [4/5] #166212
• [3/5] #166211 ⬅
• [2/5] #166210
• [1/5] #166209

⚠️ Part of a stack created by spr. Merging this PR using the GitHub UI may have unexpected results.

---

Full diff: https://github.com/llvm/llvm-project/pull/166211.diff

2 Files Affected:

• (modified) llvm/lib/CodeGen/MachineInstr.cpp (+6-2)
• (modified) llvm/test/CodeGen/SystemZ/vec-load-element.ll (+2-2)

diff --git a/llvm/lib/CodeGen/MachineInstr.cpp b/llvm/lib/CodeGen/MachineInstr.cpp
index 8ad9245a47684..37e5c517d24d8 100644
--- a/llvm/lib/CodeGen/MachineInstr.cpp
+++ b/llvm/lib/CodeGen/MachineInstr.cpp
@@ -1547,10 +1547,14 @@ bool MachineInstr::mayAlias(BatchAAResults *AA, const MachineInstr &Other,
 
   // Check each pair of memory operands from both instructions, which can't
   // alias only if all pairs won't alias.
-  for (auto *MMOa : memoperands())
-    for (auto *MMOb : Other.memoperands())
+  for (auto *MMOa : memoperands()) {
+    for (auto *MMOb : Other.memoperands()) {
+      if (!MMOa->isStore() && !MMOb->isStore())
+        continue;
       if (MemOperandsHaveAlias(MFI, AA, UseTBAA, MMOa, MMOb))
         return true;
+    }
+  }
 
   return false;
 }
diff --git a/llvm/test/CodeGen/SystemZ/vec-load-element.ll b/llvm/test/CodeGen/SystemZ/vec-load-element.ll
index 2baaed19546df..9bef279d7c0fa 100644
--- a/llvm/test/CodeGen/SystemZ/vec-load-element.ll
+++ b/llvm/test/CodeGen/SystemZ/vec-load-element.ll
@@ -5,8 +5,8 @@
 ; CHECK-LABEL: .LBB0_1:
 ; CHECK-NOT: l %r
 ; CHECK-NOT: vlvgf
-; CHECK: pfd
-; CHECK: vlef
+; CHECK-DAG: pfd
+; CHECK-DAG: vlef
 
 %type0 = type { i32, [400 x i8], i32, i32, i32, i32, i32, i32, i32, i32, i32, i32 }
 @Mem = external global [150 x %type0], align 4

[jayfoad]

This patch highlights a problem that I have run into before: if we want to support a single opcode (in this case BUNDLE) that may or may not load or store depending on its operands, then the current definitions of MachineInstr::mayLoad and mayStore are not good enough, because they just check a static property of the opcode.

If mayLoad and mayStore were more sophisticated then this check would have been handled already at L1527.

Having said that, in the short term I have no objection to this patch.

[nhaehnle]

This patch highlights a problem that I have run into before: if we want to support a single opcode (in this case BUNDLE) that may or may not load or store depending on its operands, then the current definitions of MachineInstr::mayLoad and mayStore are not good enough, because they just check a static property of the opcode.

A potential solution to this problem would be an empty MMO, i.e. an MMO that can never alias anything.

If mayLoad and mayStore were more sophisticated then this check would have been handled already at L1527.

This change aims at something subtly different. What it aims to do is improve the alias checking of two instructions with MMOs:

• load X, store Y
• load X

These two instructions don't alias, since their only overlap is in the load MMOs, which isn't a conflict.

[jayfoad]

If mayLoad and mayStore were more sophisticated then this check would have been handled already at L1527.

This change aims at something subtly different. What it aims to do is improve the alias checking of two instructions with MMOs:

• load X, store Y
• load X

These two instructions don't alias, since their only overlap is in the load MMOs, which isn't a conflict.

Yeah, I realized that later. LGTM.

[nhaehnle]

The Windows CI reports a failure, but the logs look completely clean except for this error that seems to originate from the CI infra itself:

2025-11-06T16:56:57.0555141Z + python C:/_work/llvm-project/llvm-project/.ci/generate_test_report_github.py 0 C:/_work/llvm-project/llvm-project/build/test-results.7hrcixpi.xml C:/_work/llvm-project/llvm-project/build/test-results._337lz6b.xml C:/_work/llvm-project/llvm-project/build/test-results.bkrbjuib.xml C:/_work/llvm-project/llvm-project/build/test-results.g3dbdeym.xml C:/_work/llvm-project/llvm-project/build/test-results.ll76ye1t.xml C:/_work/llvm-project/llvm-project/build/test-results.y4zoj7fv.xml C:/_work/llvm-project/llvm-project/ninja.log
2025-11-06T16:56:57.1272333Z Traceback (most recent call last):
2025-11-06T16:56:57.1272859Z   File "C:\_work\llvm-project\llvm-project\.ci\generate_test_report_github.py", line 9, in <module>
2025-11-06T16:56:57.1274006Z     import generate_test_report_lib
2025-11-06T16:56:57.1274366Z   File "C:\_work\llvm-project\llvm-project\.ci\generate_test_report_lib.py", line 13, in <module>
2025-11-06T16:56:57.1275439Z     class FailureExplanation(TypedDict):
2025-11-06T16:56:57.1275849Z   File "C:\_work\llvm-project\llvm-project\.ci\generate_test_report_lib.py", line 16, in FailureExplanation
2025-11-06T16:56:57.1276567Z     reason: str | None
2025-11-06T16:56:57.1276844Z TypeError: unsupported operand type(s) for |: 'type' and 'NoneType'
2025-11-06T16:56:57.1404087Z ##[error]Process completed with exit code 1.