[PATCH] D108247: [CUDA] Improve CUDA version detection and diagnostics.

Mon Sep 27 11:26:22 PDT 2021

tambre added a comment.

In D108247#3025238 <https://reviews.llvm.org/D108247#3025238>, @tra wrote:

> So, what's the current state of affairs regarding CUDA SDK layout in debian?

`/usr/bin`: most executables <https://packages.debian.org/bullseye/amd64/nvidia-cuda-toolkit/filelist>, `nvcc` and `nvprof` shims
`/usr/lib/nvidia-cuda-toolkit/bin`: `cicc`, `crt`, `nvcc`, `nvprof`, `g++` and `gcc` wrappers for supporting different compilers
`/usr/lib/nvidia-cuda-toolkit/libdevice`: `libdevice.10.bc`
`/usr/lib/cuda/{bin,include,lib64}`: empty directories
`/usr/lib/cuda/nvvm/libdevice`: symlinked to `/usr/lib/nvidia-cuda-toolkit/libdevice`
`/usr/include`: headers

> CUDA SDK no longer ships version.txt, so cuda.h is the only reliable mechanism for detecting CUDA version and clang does need to know it.
> In case the version has not been found we also can not choose an arbitrary old version as the default.

Agreed, sensible.

> So, one workaround would be to install CUDA-11.4. AFAICT, we do find the headers and ptxas, but misdetect CUDA version.

I don't think that's going to be acceptable for most distributions, which might ship a Clang supporting a newer CUDA than the one they ship.

> Another workaround would be to place a fake /usr/lib/cuda/include/cuda.h with something like this:

My CMake CI bot [[ https://open.cdash.org/test/498767666 | encountered `cmath` template errors ]] after I manually symlinked `/usr/lib/cuda/include` to `/usr/include`, though that solved the version detection.
Adding a shim like the one you show fixes everything and compiling works.

> Clang does rely on very particular ordering of includes, so having CUDA headers in a location clang does not expect will lead to issues sooner or later.

Having the headers in the system-wide `/usr/include` shouldn't be a problem though, right?
I'm not quite sure why simply having `/usr/lib/cuda/include` → `/usr/include` symlink breaks as seen on my bot.
Prior to this an empty `/usr/lib/cuda/include` and Clang finding them through the regular include search path worked.

> If the headers are not available where --cuda-path points clang to, I'm not sure what clang is supposed to do. Second-guessing explicit user input is not a good idea in general.

I agree that second-guessing is bad, but expecting it to be available in the include search path otherwise seems reasonable.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108247