[Mlir-commits] [mlir] [mlir][GPU] Add `RecursiveMemoryEffects` to `gpu.launch` (PR #75315)
Matthias Springer
llvmlistbot at llvm.org
Thu Dec 14 22:47:14 PST 2023
================
@@ -227,3 +243,20 @@ func.func @make_subgroup_reduce_uniform() {
}
return
}
+
+// -----
+
+// The GPU kernel does not have any side effecting ops, so the entire
----------------
matthias-springer wrote:
`RecursiveMemoryEffects` indicates that the side effects of this op are defined by the side effects of nested ops.
In essence: `gpu.launch` by itself does not have any side effects. E.g., it does not read/write to memory etc. But the GPU kernel may have ops that read/write to memory. When we use the C++ API to query the side effects of a `gpu.launch`, it will automatically check the side effects of the ops inside the kernel and return those.
If the ops in the kernel have no side effects, then the `gpu.launch` has no side effects. That's why the `gpu.launch` in the newly added test case folds away. It does to read/write to memory etc. It can just be removed.
> Once can imagine there is a llvm.ptr and it can used to build memref descriptor. It can be used inside gpu.launch body, or something else, is it safe in these cases?
When you use that memref value, e.g., with a `memref.load`, you have an op with a side effect and the entire kernel will be considered to have that side effect.
https://github.com/llvm/llvm-project/pull/75315
More information about the Mlir-commits
mailing list