[flang-commits] [flang] [Flang] Add FIR and LLVM lowering support for prefetch directive (PR #167272)

[via flang-commits]

================
@@ -353,6 +351,39 @@ def fir_StoreOp : fir_Op<"store", [FirAliasTagOpInterface,
   }];
 }
 
+def fir_PrefetchOp : fir_Op<"prefetch", []> {
+  let summary = "prefetch a memory reference";
+
+  let description = [{
+    The prefetch is a hint to the code generator that the memory reference will
+    be used in the near future. The prefetch is not guaranteed to be executed.
+
+    ```
+      %a = ... -> !fir.ref<i32>
+      fir.prefetch %a {read, data, localityHint = 3 : i32} : !fir.ref<i32>
+      // ...
+      fir.load %a : !fir.ref<i32> // use the prefetched value
+    ```
+  }];
+
+  /// `memref' is the address to be prefetched
+  /// `rw'          : rw specifier >
+  ///                  read is 0 (default), write is 1
+  /// `localityHint': temporal locality specifier >
+  ///                  value ranging from 0 - no locality to 3 - extremely local
+  /// `cacheType'   : cache type specifier >
+  ///                  instruction cache is 0, data cache is 1 (default)
+  /// NOTE: The numerical values used here is in reference to the LLVM LangRef
+  let arguments =
+      (ins Arg<AnyReferenceLike,
+               "prefetch memory address", [MemWrite]> : $memref,
----------------
jeanPerier wrote:

To add on this, I suggested going this route based on the similar patch for `memref.prefetch` https://github.com/llvm/llvm-project/pull/151261.

One suggestion to avoid the side effect was to use a token base design, but I am not sure what operation should consume the token (probably the first actual read/write to the variable, but this may be many operations in FIR/HLFIR). Maybe a new operation with could be emitted before the next use of the variable (although "the first" would need to be defined in terms of branches).

Another approach is to have the prefetch return the memory address and use that in the next symbol reference (again, also not trivial because this is not a scoped directive).

Another alternative would be to use write effect on a "virtual" resource (like fir.declare with the DebuggingResource), but this would also need to be thought through.

The MemWrite is the more robust and simple approach at that point, although I agree it may still fire back in cases where there were only reads to the memref in the loop and the MemWrite create fake iteration dependencies.

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