[Mlir-commits] [mlir] [mlir] Document GPU dialect layering to capture discussions from a PR (PR #95812)
Krzysztof Drewniak
llvmlistbot at llvm.org
Thu Jun 20 15:40:59 PDT 2024
https://github.com/krzysz00 updated https://github.com/llvm/llvm-project/pull/95812
>From f31a3cc89e632771959eb8d6d0d5b03062eb6ac5 Mon Sep 17 00:00:00 2001
From: Krzysztof Drewniak <Krzysztof.Drewniak at amd.com>
Date: Mon, 17 Jun 2024 17:05:09 +0000
Subject: [PATCH 1/4] [mlir] Document GPU dialect layering to capture
discussions from a PR
---
mlir/docs/Dialects/GPU.md | 39 ++++++++++++++++++++++++++++++++++++---
1 file changed, 36 insertions(+), 3 deletions(-)
diff --git a/mlir/docs/Dialects/GPU.md b/mlir/docs/Dialects/GPU.md
index 8a3acc33600a4..c33e16453452f 100644
--- a/mlir/docs/Dialects/GPU.md
+++ b/mlir/docs/Dialects/GPU.md
@@ -12,8 +12,36 @@ manipulations to launch a GPU kernel and provide a simple path towards GPU
execution from MLIR. It may be targeted, for example, by DSLs using MLIR. The
dialect uses `gpu` as its canonical prefix.
+This dialect also abstracts away primitives commonly available in GPU code, such
+as with `gpu.thread_id` (an operation that returns the ID of threads within
+a thread block/workgroup along a given dimension). While the compilation
+pipelines documented below expect such code to live inside a `gpu.module` and
+`gpu.func`, these intrinsic wrappers may be used outside of this context.
+
+Intrinsic-wrapping operations should not expect that they have a parent of type
+`gpu.func`. However, operations that deal in compiling and launching GPU functions,
+like `gpu.launch_func` or `gpu.binary` may assume that the dialect's full layering
+is being used.
+
[TOC]
+## GPU address spaces
+
+The GPU dialect exposes the `gpu.address_space` attribute, which currently has
+three values: `global`, `workgroup`, and `private`.
+
+These address spaces represent the types of buffer commonly seen in GPU compilation:.
+`global` memory is memory that resides in the GPU's global memory and is commonly
+used for function arguments. `workgroup` memory is a limited, per-workgroup resource:
+all threads in a workgroup/thread block access the same values in `worgroup` memory,
+but cannot access the `workgroup` memory of other workgroups. Finally, `private`
+memory is used to represent `alloca`-like buffers that are private to a sigle thread.
+
+These address spaces may be used as the `memorySpace` attribute on `memref` values,.
+The `gpu.module`/`gpu.func` compilation pipeline will lower such memory space
+usages to the correct address spaces on target platforms. Memory attributions should be
+created with the correct memory space on the memref.
+
## Memory attribution
Memory buffers are defined at the function level, either in "gpu.launch" or in
@@ -61,6 +89,11 @@ mlir-translate example-nvvm.mlir \
-o example.ll
```
+This compilation process expects all GPU code to live in a `gpu.module` and
+expects all kernels to be `gpu.func` operations. Non-kernel functions, like
+device library calls, may be defined using `func.func` or other non-GPU dialect
+operations.
+
### Default NVVM Compilation Pipeline: gpu-lower-to-nvvm-pipeline
The `gpu-lower-to-nvvm-pipeline` compilation pipeline serves as the default way
@@ -85,9 +118,9 @@ within GPU code execution:
func.func @main() {
%c2 = arith.constant 2 : index
%c1 = arith.constant 1 : index
- gpu.launch
- blocks(%0, %1, %2) in (%3 = %c1, %4 = %c1, %5 = %c1)
- threads(%6, %7, %8) in (%9 = %c2, %10 = %c1, %11 = %c1) {
+ gpu.launch
+ blocks(%0, %1, %2) in (%3 = %c1, %4 = %c1, %5 = %c1)
+ threads(%6, %7, %8) in (%9 = %c2, %10 = %c1, %11 = %c1) {
gpu.printf "Hello from %d\n" %6 : index
gpu.terminator
}
>From 64f251f6de259a6dd75d1032b24daa8a1806ab38 Mon Sep 17 00:00:00 2001
From: Krzysztof Drewniak <Krzysztof.Drewniak at amd.com>
Date: Mon, 17 Jun 2024 22:38:15 -0500
Subject: [PATCH 2/4] Fix typo
Co-authored-by: Jakub Kuderski <kubakuderski at gmail.com>
---
mlir/docs/Dialects/GPU.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mlir/docs/Dialects/GPU.md b/mlir/docs/Dialects/GPU.md
index c33e16453452f..89d71d4580cd9 100644
--- a/mlir/docs/Dialects/GPU.md
+++ b/mlir/docs/Dialects/GPU.md
@@ -37,7 +37,7 @@ all threads in a workgroup/thread block access the same values in `worgroup` mem
but cannot access the `workgroup` memory of other workgroups. Finally, `private`
memory is used to represent `alloca`-like buffers that are private to a sigle thread.
-These address spaces may be used as the `memorySpace` attribute on `memref` values,.
+These address spaces may be used as the `memorySpace` attribute on `memref` values.
The `gpu.module`/`gpu.func` compilation pipeline will lower such memory space
usages to the correct address spaces on target platforms. Memory attributions should be
created with the correct memory space on the memref.
>From c478567988e195a65bbfed1b9081affe7c6f622b Mon Sep 17 00:00:00 2001
From: Krzysztof Drewniak <Krzysztof.Drewniak at amd.com>
Date: Wed, 19 Jun 2024 23:17:15 +0000
Subject: [PATCH 3/4] Adjust per feedback
---
mlir/docs/Dialects/GPU.md | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/mlir/docs/Dialects/GPU.md b/mlir/docs/Dialects/GPU.md
index 89d71d4580cd9..53341cf76a3a3 100644
--- a/mlir/docs/Dialects/GPU.md
+++ b/mlir/docs/Dialects/GPU.md
@@ -30,12 +30,11 @@ is being used.
The GPU dialect exposes the `gpu.address_space` attribute, which currently has
three values: `global`, `workgroup`, and `private`.
-These address spaces represent the types of buffer commonly seen in GPU compilation:.
-`global` memory is memory that resides in the GPU's global memory and is commonly
-used for function arguments. `workgroup` memory is a limited, per-workgroup resource:
-all threads in a workgroup/thread block access the same values in `worgroup` memory,
-but cannot access the `workgroup` memory of other workgroups. Finally, `private`
-memory is used to represent `alloca`-like buffers that are private to a sigle thread.
+These address spaces represent the types of buffer commonly seen in GPU compilation.
+`global` memory is memory that resides in the GPU's global memory. `workgroup`
+memory is a limited, per-workgroup resource: all threads in a workgroup/thread
+block access the same values in `worgroup` memory. Finally, `private` memory is
+used to represent `alloca`-like buffers that are private to a single thread/workitem.
These address spaces may be used as the `memorySpace` attribute on `memref` values.
The `gpu.module`/`gpu.func` compilation pipeline will lower such memory space
@@ -92,7 +91,11 @@ mlir-translate example-nvvm.mlir \
This compilation process expects all GPU code to live in a `gpu.module` and
expects all kernels to be `gpu.func` operations. Non-kernel functions, like
device library calls, may be defined using `func.func` or other non-GPU dialect
-operations.
+operations. This permits downstream systems to use these wrappers witout
+requiring them to use the GPU dialect's function operations, which might not include
+information those systems want to have as intrinsic values on their functions.
+Additionally, this allows for using `func.func` for device-side library functions
+in `gpu.module`s.
### Default NVVM Compilation Pipeline: gpu-lower-to-nvvm-pipeline
>From ccfa49dfe68845fabb7d3dd7e4f87ac6dcd8cec8 Mon Sep 17 00:00:00 2001
From: Krzysztof Drewniak <Krzysztof.Drewniak at amd.com>
Date: Thu, 20 Jun 2024 17:40:51 -0500
Subject: [PATCH 4/4] ]Fix typos
Co-authored-by: Adam Siemieniuk <adam.siemieniuk at intel.com>
---
mlir/docs/Dialects/GPU.md | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mlir/docs/Dialects/GPU.md b/mlir/docs/Dialects/GPU.md
index 53341cf76a3a3..fec718e8d18b8 100644
--- a/mlir/docs/Dialects/GPU.md
+++ b/mlir/docs/Dialects/GPU.md
@@ -33,7 +33,7 @@ three values: `global`, `workgroup`, and `private`.
These address spaces represent the types of buffer commonly seen in GPU compilation.
`global` memory is memory that resides in the GPU's global memory. `workgroup`
memory is a limited, per-workgroup resource: all threads in a workgroup/thread
-block access the same values in `worgroup` memory. Finally, `private` memory is
+block access the same values in `workgroup` memory. Finally, `private` memory is
used to represent `alloca`-like buffers that are private to a single thread/workitem.
These address spaces may be used as the `memorySpace` attribute on `memref` values.
@@ -91,7 +91,7 @@ mlir-translate example-nvvm.mlir \
This compilation process expects all GPU code to live in a `gpu.module` and
expects all kernels to be `gpu.func` operations. Non-kernel functions, like
device library calls, may be defined using `func.func` or other non-GPU dialect
-operations. This permits downstream systems to use these wrappers witout
+operations. This permits downstream systems to use these wrappers without
requiring them to use the GPU dialect's function operations, which might not include
information those systems want to have as intrinsic values on their functions.
Additionally, this allows for using `func.func` for device-side library functions
More information about the Mlir-commits
mailing list