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.
- 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 and 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