[flang-commits] [flang] [llvm] [mlir] [Flang] [OpenMP] atomic compare (PR #184761)

[Tom Eccles via flang-commits]

================
@@ -4769,17 +4769,53 @@ convertOmpAtomicCompare(omp::AtomicCompareOp atomicCompareOp,
   llvm::AtomicOrdering atomicOrdering =
       convertAtomicOrdering(atomicCompareOp.getMemoryOrder());
 
-  // Trace back through load operations and generate load instructions
+  auto isAtomicComparePatternOp = [](Operation &op) {
+    return llvm::isa<LLVM::ICmpOp, LLVM::FCmpOp, LLVM::SelectOp,
+                     LLVM::AndOp, LLVM::OrOp>(op);
+  };
+
+  // Pre-translate operations inside the region that compute intermediate values
+  // (e.g., memcpy, GEP, loads for dereferencing Fortran pointers) but are not
+  // part of the atomic compare-and-swap pattern itself. This ensures all
+  // intermediate values are available in the moduleTranslation mapping when
+  // extracting eVal and dVal below.
+  for (Operation &op : block.without_terminator()) {
+    // Skip operations that form the atomic compare pattern — these are
+    // analyzed separately below.
+    if (isAtomicComparePatternOp(op))
+      continue;
----------------
tblah wrote:

If the atomic compare pattern comes before the other operations then we would need to prove that the memory effects of those operations do not change the meaning of the compare pattern.

I think that can't happen? But I think this needs some documentation explaining why the transformation is valid and documentation on the atomic compare operation enforcing any assumptions made here (if it isn't there already)

https://github.com/llvm/llvm-project/pull/184761