[Openmp-commits] [PATCH] D73076: [libomptarget] Implement hip atomic functions in terms of intrinsics
Jon Chesterfield via Phabricator via Openmp-commits
openmp-commits at lists.llvm.org
Tue Jan 21 15:37:06 PST 2020
JonChesterfield added a comment.
In D73076#1832492 <https://reviews.llvm.org/D73076#1832492>, @jdoerfert wrote:
> Is is necessary, or useful, to have 3 different kinds of intrinsics here? We have `__atomic_fetch_max` and `__atomic_max_fetch` in clang, unsure if they could replace the OpenCL intrinsic. Similarly, there is `__atomic_compare_exchange` and `__atomic_exchange`. I would also be fine with only __amdgcn intrinsics or only __opencl ones but I am a little worried about mixing these 3 kinds.
I share this concern. I especially dislike the forced cast to _Atomic T* for the opencl intrinsics as that's skirting a bit close to an aliasing violation.
atomic_fetch_max I missed because gcc doesn't document it. In clang, it only compiles for 32 bit integer types (and we have a use of 64 bit in loop.cu). Some context in D46386 <https://reviews.llvm.org/D46386>.
I remember seeing different codegen for the opencl compare_exchange and the builtin but am not able to reproduce that now. There was some trial and error choosing intrinsics while comparing the codegen to hand written IR.
How about generic intrinsics where available:
- fetch_add
- exchange
- compare_exchange
Amdgcn prefixed IR functions for:
- atomic_inc
- atomic_fetch_max
with the intent to provide amdgcn intrinsics for inc and fetch_max?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D73076/new/
https://reviews.llvm.org/D73076
More information about the Openmp-commits
mailing list