tra added a comment. In D77451#1964971 <https://reviews.llvm.org/D77451#1964971>, @sammccall wrote:
> > 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 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. ================ Comment at: clang/lib/Tooling/InterpolatingCompilationDatabase.cpp:119 + case types::TY_CUDA_DEVICE: + case types::TY_CUDA_FATBIN: + return types::TY_CUDA: ---------------- sammccall wrote: > tra wrote: > > I don't think you need CUDA_FATBIN for clangd. If your input is .fatbin, > > the source code has been long gone. > 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. 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. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D77451/new/ https://reviews.llvm.org/D77451 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
