Return values from async regions as !async.value<...>.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/include/mlir/Dialect/Async/IR/AsyncBase.td | ||
---|---|---|
51 | ||
mlir/lib/Dialect/Async/IR/Async.cpp | ||
74 | Can you add a class doc (something simple like "Storage for async.value<T> type, the only member is the wrapped type.") | |
103 | Please fix :) | |
106 | This can fail, you need to check in the verifier. Also I rather be more strict here: we really want to map the immediate parent only: | |
114 | Nit: remote trivial braces. | |
131 | interleaveComma should do it here. This can't be done in the assembly format by the way? You're also missing attribute printing |
Verify async.yield op parent
mlir/lib/Dialect/Async/IR/Async.cpp | ||
---|---|---|
106 | Didn't find anything like that in the generated file, added the check to this function. |
mlir/lib/Dialect/Async/IR/Async.cpp | ||
---|---|---|
106 | You're right: the HasParent trait will verify it (there isn't a specific verification in the TableGen generated file, it is dispatched to the trait by the simple fact of inheriting from it) |
Do not check async.yield parent op in verifier, it is already checked by HasParent trait.
Looks good!
Just name bike shedding: I assume you considered both async.value and async.future. What's your reason to pick async.value?
When I was writing this PR I didn't see the async.future proposal ;) Although I'm not a fan of async.future because both async and future have very similar semantics, and having them both in the same type looks weird to me. I'm fine changing it to future, if people have strong opinion about that. I'll prepare the next PR with async arguments, and then we can change the type if needed.
I see where you are coming from. I look at !async.<type> as <type> in the async dialect, and that way future makes more sense than value.