[Mlir-commits] [mlir] [mlir][nvgpu] update commit group and wait async ops (PR #130482)

lonely eagle llvmlistbot at llvm.org
Mon Mar 17 07:21:40 PDT 2025


linuxlonelyeagle wrote:

* Introducing this thing should be hoped to enable better analysis.But I think this thing is too hack.This makes normal usage not easy to use.
The follow is an nstage algorithm.
```
// prefetch data
%token = async.cp
%token_0 = commit_group %token

// cp op and commit op should be nstage - 1 times.

loop args(%token_0,...) { // nstage - 1 tokens
   wait [%token_0, ...]
   compute Ops
   // prefetch data
   %token_0 = async.cp
   %token_1 = commit_group %token
   // nstage - 1 times.
   yield % token_1, ...
}
```
It seems to me that there is no need to put so many parameters in the loop.
* The semantic confusion
```
%token = async.cp
%token_0 = commit_group %token

%token_1 = async.cp
%token_2 = commit_group %token_1
```
Regarding the above situation,Aren't the following usages the same?
```
// wait all cp1 and cp2
async_wait {num_groups = 0}
async_wait [%token_1] {num_groups = 0}
async_wait [%token_1, %token_2] {num_groups = 0}
```
Like the example I left in a recent comment, it also has problems.The current changes are closer to the original semantics of PTX.People familiar with PTX will immediately know how to use these Ops.
* Taking a step back, if we cancel the dependent groups, will it be difficult to analyze the groups that the current async_wait op is waiting for.Maybe it is not difficult to do. Enough information is kept on IR.


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


More information about the Mlir-commits mailing list