- accept -x cu to indicate language is CUDA
- transfer CUDA language flag to header-file arguments
Please add some more details to the bug description. This change is to make clangd work when compilation database sees CUDA sources compiled with nvcc. NVCC uses different options that should be properly translated. This patch only deals with recognizing the sources as CUDA, but does not handle the compiler options. While not perfect, it's still a useful improvement.
It would be great to extract CUDA path from nvcc's command line and add it as --cuda-path=.... I believe clang-based tools are not doing as much as clang itself when it comes to guessing CUDA location. Without it it will pick up CUDA from the default location (if at all) and that may not be the CUDA used during the build.
I don't think you need CUDA_FATBIN for clangd. If your input is .fatbin, the source code has been long gone.
NVCC uses different options that should be properly translated
Interested to see how this will work. Is clang itself going to support these args (act compatibly with nvcc, or is the idea that just tools will be?
I think this could be clearer: "Accept "cu" as an alias for "cuda" for NVCC compatibility"
This establishes equivalence classes within which it makes sense to transfer command-line flags. So if you might have compile_commands.json entries building .fatbin inputs, and those flags are a sensible template for building *.cu.cc files, then you want fatbin here, otherwise not.
I don't think it makes a lot of sense to create nvcc-compatible driver. Even if we did, we'd still have to handle things in the tooling library, too, in a way similar to what we currently do for cl or clang-cl. Argument translation could use some refactoring, too, to make it more generic and easier to adapt.
Both nvcc and clang can build .ptx (nvcc's -ptx, clang's --cuda-device-only -S) or .cubin (-cubin and --cuda-device-only -c). I believe neither nvcc not clang expose fatbin as a compilation result. It's purely for internal driver use in both cases.
Thank you for the patch. I assume you don't have commit access to LLVM. I can land the patch for you.
How should I attribute it? Will ADRA <firstname.lastname@example.org> (used in phabricator emails) do or do you prefer some other form?