This op could naturally be combined with gpu.create_token, by making a token result optional: If it returns a token, it behaves like create_token. Otherwise, it behaves like host_wait.
I do like the idea of combining them, but I don't have a good name for it, and the two use cases are quite different (create_token is created by lowering within GPU only, host_wait is added upstream).
Details
Details
- Reviewers
herhut
Diff Detail
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/include/mlir/Dialect/GPU/GPUOps.td | ||
---|---|---|
776 | Hmm, is this op really asynchronous? I find it strange that it implements this interface. It also breaks the assumption that all asynchronous operations return a token to sync on their effects. Also, as all operands of this op are tokens, we already naturally have a way to add extra operands. | |
787 | Is this actually needed? | |
794 | I like the syntax with [] for tokens. But as this is not an async operation, maybe it should have the tokens as proper operands with ()? |
Hmm, is this op really asynchronous? I find it strange that it implements this interface. It also breaks the assumption that all asynchronous operations return a token to sync on their effects.
Also, as all operands of this op are tokens, we already naturally have a way to add extra operands.