| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[mlir][NFC] Update textual references of func to func.func in AMX/Arithmetic/ArmSVE/Async tests The special case parsing of func operations is being removed. | 4 年前 | |
[mlir][NFC] Update textual references of func to func.func in AMX/Arithmetic/ArmSVE/Async tests The special case parsing of func operations is being removed. | 4 年前 | |
[mlir][async] Avoid crash when not using func.func (#72801) The createParallelComputeFunction crashed when calling getFunctionTypeAttrName during the creation of a new FuncOp inside the pass. The problem is that getFunctionTypeAttrName looks up the attribute name for the function type which in this case is func.func. However, name.getAttributeNames() was empty when clients used llvm.func instead of func.func. To fix this, the func dialect is now registered as a dependent dialect. Also, I've added an assertion which could save other people some time. Fixes #71281, fixes #64326. | 2 年前 | |
[mlir][NFC] Update textual references of func to func.func in AMX/Arithmetic/ArmSVE/Async tests The special case parsing of func operations is being removed. | 4 年前 | |
[mlir][NFC] Update textual references of func to func.func in AMX/Arithmetic/ArmSVE/Async tests The special case parsing of func operations is being removed. | 4 年前 | |
[mlir][NFC] Update textual references of func to func.func in AMX/Arithmetic/ArmSVE/Async tests The special case parsing of func operations is being removed. | 4 年前 | |
[mlir][NFC] Update textual references of func to func.func in AMX/Arithmetic/ArmSVE/Async tests The special case parsing of func operations is being removed. | 4 年前 | |
[mlir][NFC] Update textual references of func to func.func in AMX/Arithmetic/ArmSVE/Async tests The special case parsing of func operations is being removed. | 4 年前 | |
Splits cleanup block lowered by AsyncToAsyncRuntime. (#66123) Splits the cleanup block lowered from AsyncToAsyncRuntime. The incentive of this change is to clarify the CFG branched by async.coro.suspend. The async.coro.suspend op branches into 3 blocks, depending on the state of the coroutine: 1) suspend 2) resume 3) cleanup The behavior before this change is that after the coroutine is resumed and completed, it will jump to a shared cleanup block for destroying the states of coroutines. The CFG looks like the following, Entry block | \ resume | | | Cleanup | End This CFG can potentially be problematic, because the Cleanup block is a shared block and it is not dominated by resume. For instance, if some pass wants to add some specific cleanup mechanism to resume, it can be confused and add them to the shared Cleanup, which leads to the "operand not dominate its use" error because of the existence of the other "Entry->cleanup" path. After this change, the CFG will look like the following, The overall structure of the lowered CFG can be the following, Entry (calling async.coro.suspend) | \ Resume Destroy (duplicate of Cleanup) | | Cleanup | | / End (ends the corontine) In this case, the Cleanup block tied to the Resume block will be isolated from the other path and it is strictly dominated by "Resume". | 2 年前 | |
[mlir][async]: Make async.execute operation with RecursiveMemoryEffects trait (#116544) | 11 个月前 | |
[mlir][NFC] Update textual references of func to func.func in AMX/Arithmetic/ArmSVE/Async tests The special case parsing of func operations is being removed. | 4 年前 | |
Add Async Function to the Async Dialect Add Async Function to the Async Dialect Today async.execute operation semantics requires attached region to be executed in a thread managed by the runtime, and always returns an !async.token result. We need to model async functions that are not necessarily executed in a runtime-managed threads, but eventually lowered to llvm coroutines. Example: async.func @foo(%arg0: !async.value<f32>) -> !async.token { %0 = async.await %arg0: !async.value<f32> "do_something_with_f32"(%0) return } If arg0 is available this function will be executed in the caller thread. If it's not available it will be suspended and resumed later later on a thread managed by the async runtime. Currently this is not representable with async.execute operations. The longer term goal is to make async dialect more like https://github.com/lewissbaker/cppcoro to be able to represent structured host concurrency in MLIR. (1) Add async.func, async.call, and async.return operations in Async Dialect Reviewed By: ezhulenev, rriddle Differential Revision: https://reviews.llvm.org/D137189 | 3 年前 | |
[mlir][NFC] Update textual references of func to func.func in AMX/Arithmetic/ArmSVE/Async tests The special case parsing of func operations is being removed. | 4 年前 | |
Add Async Function to the Async Dialect Add Async Function to the Async Dialect Today async.execute operation semantics requires attached region to be executed in a thread managed by the runtime, and always returns an !async.token result. We need to model async functions that are not necessarily executed in a runtime-managed threads, but eventually lowered to llvm coroutines. Example: async.func @foo(%arg0: !async.value<f32>) -> !async.token { %0 = async.await %arg0: !async.value<f32> "do_something_with_f32"(%0) return } If arg0 is available this function will be executed in the caller thread. If it's not available it will be suspended and resumed later later on a thread managed by the async runtime. Currently this is not representable with async.execute operations. The longer term goal is to make async dialect more like https://github.com/lewissbaker/cppcoro to be able to represent structured host concurrency in MLIR. (1) Add async.func, async.call, and async.return operations in Async Dialect Reviewed By: ezhulenev, rriddle Differential Revision: https://reviews.llvm.org/D137189 | 3 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 4 年前 | ||
| 4 年前 | ||
| 2 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 2 年前 | ||
| 11 个月前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 3 年前 |