[PATCH] D77451: Accept -x cu to indicate language is CUDA, transfer CUDA language flag to header-file arguments

Mon Apr 6 13:37:58 PDT 2020

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