[Openmp-commits] [PATCH] D71404: [libomptarget][nfc] Introduce atomic wrapper function
Johannes Doerfert via Phabricator via Openmp-commits
openmp-commits at lists.llvm.org
Thu Dec 12 19:28:35 PST 2019
jdoerfert added a comment.
In D71404#1782914 <https://reviews.llvm.org/D71404#1782914>, @JonChesterfield wrote:
> There's an outstanding design point here.
>
> Logically, the implementation is per target so should be in arch/src/target_atomic.h, with call sites including target_atomic.
>
> However, the nvptx and amdgcn implementations will be (somewhat spuriously) the same. So either copy & paste time, or each needs to include a header from common containing the implementation which is otherwise not included anywhere.
>
> This awkward redirection is necessary under the current scheme to allow a new arch to provide a header that is picked up by common/src/foo.cpp.
>
> I wonder if that means a different redirection scheme is better, e.g. where headers are used from common unless one with the same name is provided under the arch. That seems error prone however.
//To be honest, I did not follow this so if my response doesn't make sense let me know.//
Could we have a generic atomic header with the template definition that is something like this:
template <typename T> T __kmpc_impl_atomic_exchange(T *Ptr, T Val) {
T Tmp;
#pragma omp atomic
{ Tmp = *Ptr; *Ptr = Val; }
return Tmp;
}
In the `target_impl.h` you can provide the specialized implementation.
template <typename T> T __kmpc_impl_atomic_exchange(T *Ptr, T Val) {
return atomicExch(Ptr, Val);
}
Only one template version will be visible at any time. Would that solve the problem?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D71404/new/
https://reviews.llvm.org/D71404
More information about the Openmp-commits
mailing list