================
@@ -1099,14 +1100,21 @@ def AMDGPU_GatherToLDSOp :
* `$transferType`: type of the data to be transferred by each thread. This
is used to determine
the size of the data to be transferred and the number of threads in the
subgroup.
The transfer type must be a scalar type or a vector type with a single
element type.
+ * If `$async` is set, the compiler will not attempt to infer the
+ memory waits needed to ensure that the DMA operation has succeeded
+ before a load that might access the stored-to LDS is performed.
+ Instead, the `rocdl.asyncmark` and `rocdl.wait.asyncmark N`
+ operations must be used to explicitly indicate the desired completion
+ behavior. This enables more precise calculation of these waits at the
+ cost of requiring user management of asynchrony.
The `$dst`, along with its indices, points to the memory location the
subgroup of this thread
will write to.
Note: only supported on gfx9 and gfx10.
}];
let assemblyFormat = [{
- $src `[` $srcIndices `]` `,` $dst `[` $dstIndices `]` attr-dict `:`
$transferType `,` type($src) `,` type($dst)
+ (`async` $async^)? $src `[` $srcIndices `]` `,` $dst `[` $dstIndices `]`
attr-dict `:` $transferType `,` type($src) `,` type($dst)
----------------
krzysz00 wrote:
`amdgpu.sched_barrier` is allowed because the enum there is adding ergonomic
value - it makes the IR clearer than the integer constants you get in ROCDL
I wrote up some documentation on this, but to roughly summarize, amdgpu-level
wrappers come in to interact with the MLIR type system in a richer way, for
meaningful ergonomic improvements (representing enums, say), and/or if you need
to create an extended version of an intrinsic that you're planning to
unroll/bitcast/... .
That is, `amdgpu.sched_barrier` has a reason to exist, `amdgpu.s.sleep` would
*not* because it's exactly 1:1 with its rocdl counterpart.
(Or, to put it another way, there's no point is wasting bytes on a rewriter
that just changes the op name)
https://github.com/llvm/llvm-project/pull/181082
_______________________________________________
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
