[Openmp-commits] [PATCH] D83591: [OpenMP][CUDA] Fix std::complex in GPU regions

Artem Belevich via Phabricator via Openmp-commits openmp-commits at lists.llvm.org
Fri Jul 10 18:11:24 PDT 2020


tra added a comment.

In D83591#2145512 <https://reviews.llvm.org/D83591#2145512>, @JonChesterfield wrote:

> In D83591#2145437 <https://reviews.llvm.org/D83591#2145437>, @jdoerfert wrote:
>
> > I did not know they are using __clang_cuda headers. (Site note, we should rename them then.)
>
>
> I also did not know that. I am repeatedly caught out by things named 'cuda', 'nvptx' or '__nv' being used by amdgpu.


It's complicated. :-)

Originally clang's headers were written to tactically fill in the gaps in the CUDA SDK headers that clang could not deal with.
OpenMP grew NVPTX back-end support and wanted to use a subset of those headers that happened to be conveniently close to math.h
AMD's HIP shares C++ front-end with CUDA and wants to benefit from the standard library glue we've implemented for CUDA. It also uses a lot of things internally that were originally targeting CUDA, but are now reused for HIP as well. Hence there are number of places where 'cuda' things do the double duty during HIP compilation. So do some of the CUDA-related headers.

> Perhaps we should refactor the __clang_cuda_* headers to make the distinctions between cuda, hip, openmp-nvptx, openmp-amdgcn clear(er).

Agreed.

Balancing OpenMP and CUDA constraints was interesting. With HIP in the picture, it will be even more so. TBH at the moment I do not see a clean way to satisfy all users of GPU-related things in clang. That said, now may be a good time to deal with this. AMD has made a lot of progress making clang work for targeting AMD GPUs and it will likely see a lot more use relatively soon. We do want to keep things working for all parties involved.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D83591/new/

https://reviews.llvm.org/D83591





More information about the Openmp-commits mailing list