aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/Frontend/CompilerInvocation.cpp
diff options
context:
space:
mode:
authorChristian Sigg <csigg@google.com>2020-10-13 17:21:59 +0200
committerChristian Sigg <csigg@google.com>2020-10-13 17:30:59 +0200
commitdb1cf3d9ab33f56fcaea616baa71c6e4036beffa (patch)
tree65394cd543dc753549b151ad1e6d82a555640301 /clang/lib/Frontend/CompilerInvocation.cpp
parentb59d8d7c72546bf3f81889f4ce02a68c902eddd2 (diff)
downloadllvm-db1cf3d9ab33f56fcaea616baa71c6e4036beffa.zip
llvm-db1cf3d9ab33f56fcaea616baa71c6e4036beffa.tar.gz
llvm-db1cf3d9ab33f56fcaea616baa71c6e4036beffa.tar.bz2
[mlir][gpu] Add `gpu.wait` op.
This combines two separate ops (D88972: `gpu.create_token`, D89043: `gpu.host_wait`) into one. I do after all like the idea of combining the two ops, because it matches exactly the pattern we are going to have in the other gpu ops that will implement the AsyncOpInterface (launch_func, copies, alloc): If the op is async, we return a !gpu.async.token. Otherwise, we synchronize with the host and don't return a token. The use cases for `gpu.wait async` and `gpu.wait` are further apart than those of e.g. `gpu.h2d async` and `gpu.h2d`, but I like the consistent meaning of the `async` keyword in GPU ops. Reviewed By: herhut Differential Revision: https://reviews.llvm.org/D89160
Diffstat (limited to 'clang/lib/Frontend/CompilerInvocation.cpp')
0 files changed, 0 insertions, 0 deletions