[Openmp-commits] [PATCH] D70971: [libomptarget] Build a minimal deviceRTL for amdgcn

Tue Dec 3 11:38:28 PST 2019

JonChesterfield marked an inline comment as done.
JonChesterfield added inline comments.

================
Comment at: openmp/libomptarget/deviceRTLs/amdgcn/CMakeLists.txt:16-18
+  $ENV{HOME}/rocm/aomp
+  /opt/rocm/aomp
+  /usr/lib/rocm/aomp
----------------
JonChesterfield wrote:
> ABataev wrote:
> > JonChesterfield wrote:
> > > ABataev wrote:
> > > > We can't build the runtime with regular clang?
> > > Sure, it builds fine with trunk. I'm using a local build of clang 9.0 on one machine and the openmp/fortran fork on a second.
> > > 
> > > The find package seems to be a list of anywhere that clang might plausibly be found. Copied straight out of our fork, happy to remove any entries you don't like the look of.
> > > 
> > > The NVPTX_CUDA_COMPILER_DIR doesn't seem especially appropriately named. I use the same compiler for nvptx and for amdgcn.
> > Can we then just use the clang (I think, you proposed this for nvcc) to build the runtime? Why shall we lookup for `rocm/aomp`?
> Which clang? CMAKE_CXX_COMPILER_DIR may resolve to gcc. Or do you mean introduce LIBOMPTARGET_AMDGCN_CUDA_COMPILER_DIR and expect the user to match that up to a clang build?
rocm/aomp is a likely location to find clang if using the rocm developer tools stack, and I think it gets installed into different places depending on whether it's from apt-get or github.

I'm a little unclear on how in tree compiler plus out of tree library (e.g. libc, opencl runtime, or the cuda toolchain) is supposed to work logistically.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70971