Request for Clang as an Alternative CUDA Compiler

[luigifcruz]

Previous pull-requests #3919 and #4835 originated from the #1003 issue, introduced native CUDA support for Meson using the NVCC compiler. In that same issue, user @trivialfis proposed also supporting LLVM's CUDA compiler as an alternative to NVCC. This very functionality was discussed the previous year by CMake developers and merged in 2020.

Yes, the Clang implementation of CUDA always lags behind the official NVCC support, as noted by @obilaniu's comment. But it's still useful to have the ability to use an alternative compiler like Clang. In particular to run C++17 or even C++20 applications with CUDA 10.1. Which is the last version of CUDA that the Jetson Nano will ever support which only compiles C++14. This ability also gives the developer better error messages, as stated by @trivialfis' comment.

My feature request is to add the ability to select which CUDA compiler to use (NVCC or Clang) in the CUDA Module for Meson. Similar to the CMAKE_CUDA_COMPILER from CMake.

P.S.: I enjoy using Meson. Thanks for developing this breath of fresh air. :smiley:

[obilaniu]

@luigifcruz @dcbaker I'm not sure this is entirely appropriately categorized under module:cuda since it really concerns adding a new compiler. The unstable CUDA module, at present, has about two useful functions - converting a list of CUDA arch's to nvcc -gencode flags, and reporting the minimum NVIDIA driver version for a given CUDA Toolkit version. Both are tedious/impossible to implement in raw Meson, so they have their place, but Meson modules are not capable of defining new compilers as far as I know (and shouldn't).

Per the LLVM documentation, it seems that Clang must be configured to support CUDA and that the CUDA Toolkit itself must be installed (even if NVCC isn't used) and indicated with --cuda-path= if not in a default location. The highest supported CUDA Toolkit version is 10.1. Furthermore, support on macOS or Windows is not guaranteed.

It would seem ideal for the maintainers of the ClangCompiler to add detection support, but this raises difficult questions about how to communicate a value of the --cuda-path= argument to Meson, whether a new -Db_* build argument is required, and what interactions there are with the dependency('cuda') code (which is a third ballgame after the CUDA compilers and CUDA module).

[dcbaker]

@obilaniu I wasn't sure if the clang interface used the same -gencode flags or not, but if we were going to add clang-cuda support the module would need to do the right thing automatically (even if that means returning an empty list) I think.

[obilaniu]

@dcbaker Clang definitely does not use the same -gencode syntax (more like -ccc-cuda-arch IIRC)

Currently the CUDA module function receives a CUDA version string as input and not a compiler instance, so it cannot tell whether Clang or NVCC are in use. I think I'd prefer to add a new function or style: 'clang' to the CUDA module to return Clang-style arguments, or else grant the Meson CUDA compiler objects an extra method .arch_flags() that could be implemented accordingly.

One thing I like about a function that receives a string and returns strings is that it's testable without a Clang compiler handy (see the test-cases).

[dcbaker]

@obilaniu but it can lookup the cuda compiler internally from the ModuleState. It really just leaves question of whether it will pick the right machine.

[obilaniu]

It really just leaves question of whether it will pick the right machine.

That's another problem handily solved by extending the compiler object with an .arch_flags() method for CUDA compiler instances only.

[SeeRich]

@luigifcruz, wow, I wasn't aware that LLVM CUDA support would even work on the Jetson Nano. Have you had success with this (without regards to meson support)? For example, can you compile C++20 code with CUDA 10.2 on the Nano platform?