[Openmp-commits] [PATCH] D89974: [driver][CUDA] Use CMake's FindCUDA as default --cuda-path.

Michael Kruse via Phabricator via Openmp-commits openmp-commits at lists.llvm.org
Thu Oct 22 10:27:22 PDT 2020


Meinersbur created this revision.
Meinersbur added reviewers: jdoerfert, RaviNarayanaswamy, ye-luo, jhuber6, phosek, grokos, tambre, rnk, sylvestre.ledru, gtbercea, tra, yaxunl, Hahnfeld, jdenny.
Meinersbur added a project: clang.
Herald added subscribers: openmp-commits, dang, ormris, mgorny.
Herald added a project: OpenMP.
Meinersbur requested review of this revision.
Herald added a subscriber: sstefan1.

Add the introspection result from `find_package(CUDA)` as the first candidate when looking for a CUDA installation. This allows specifying the path to the CUDA installation when configuring LLVM instead of in every invocation of clang. Clang and libomptarget both use CMake's introspection to determine the CUDA environment, in particular to determine the default and supported architectures for OpenMP. libomptarget's regression tests assume that clang will find the CUDA installation itself without passing --cuda-path. Ideally, these are consistent. Making Clang also use the CMake introspection was the preferred solution from the OpenMP Multi-Company conference call over adding --cuda-path to every regression test.

To not make the driver regression test dependendent on the build configuration, a new flag `--cuda-path-ignore-cmake` is added which causes the  CUDA_TOOLKIT_ROOT_PATH to not be added to the list of installation candidates.

Some notes:

- Both libomptarget and clang have a workaround for http://bugs.debian.org/882505 (CUDA on Debian and Ubuntu installations with /usr/lib/cuda prefix instead of /usr), but implemented very differently. Also see D40453 <https://reviews.llvm.org/D40453> and D55588 <https://reviews.llvm.org/D55588>). In my Ubuntu LTS versions 18.04 and 20.04, this seem to be fixed as /usr/lib/cuda still exists but only contain  the files `version.txt` and `libdevice.10.bc` (though as symbolic link directory), which happen to be the files Clang looks for when searching a CUDA installation. I assume this is a compatibility workaround to not break Clang's compatibility workaround. libomptarget's implementation was to overwrite CUDA_TOOLKIT_ROOT_DIR after invoking FindCUDA, which is an evil thing to do. I replaced it with a `PATHS "/usr/lib/cuda"` so FindCUDA can check that path itself for older distributions which indeed have CUDA installed there.
- find_package(CUDA) is deprecated by find_package(CUDAToolkit) in CMake 3.17. The required version for LLVM currently is CMake 3.13.4


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D89974

Files:
  clang/CMakeLists.txt
  clang/include/clang/Config/config.h.cmake
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Cuda.cpp
  clang/test/Driver/cuda-detect-path.cu
  clang/test/Driver/cuda-detect.cu
  openmp/libomptarget/cmake/Modules/LibomptargetGetDependencies.cmake

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D89974.300017.patch
Type: text/x-patch
Size: 19681 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/openmp-commits/attachments/20201022/4b03d19b/attachment-0001.bin>


More information about the Openmp-commits mailing list