Accept -x cu to indicate language is CUDA, transfer CUDA language flag to header-file arguments

[ADRAADRA]

Summary

• accept -x cu to indicate language is CUDA
• transfer CUDA language flag to header-file arguments

[tra]

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.

clang/lib/Tooling/InterpolatingCompilationDatabase.cpp

119

I don't think you need CUDA_FATBIN for clangd. If your input is .fatbin, the source code has been long gone.

[sammccall]

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?

clang/lib/Driver/Types.cpp

298

I think this could be clearer: "Accept "cu" as an alias for "cuda" for NVCC compatibility"

clang/lib/Tooling/InterpolatingCompilationDatabase.cpp

119

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.

[tra]

In 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.

clang/lib/Tooling/InterpolatingCompilationDatabase.cpp

119

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.

[ADRAADRA]

• Update Types.cpp comment
• remove types::TY_CUDA_FATBIN from switch

[tra]

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 <[e-mail]> (used in phabricator emails) do or do you prefer some other form?

[ADRAADRA]

In D77451#1970461, @tra wrote:

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 <[e-mail]> (used in phabricator emails) do or do you prefer some other form?

Can you use ADRA <[e-mail]>? That's my public email. Thanks!

[ctetreau]

clang/lib/Tooling/InterpolatingCompilationDatabase.cpp

119

Syntax error here, master is broken

[ctetreau]

clang/lib/Tooling/InterpolatingCompilationDatabase.cpp

119

I went ahead and fixed it.

https://github.com/llvm/llvm-project/commit/2a1418f242ab17d8d8fef6fe829fc1b9363877ca

[tra]

Thank you! A apologize for not checking the patch before landing it.

clang/lib/Driver/Types.cpp

         strcmp(Name, getInfo(Id).Name) == 0)
       return Id;
   }
-
+  // Accept "cu" as an alias for "cuda" for NVCC compatibility
+  if (strcmp(Name, "cu") == 0) {
+    return types::TY_CUDA;
+  }
   return TY_INVALID;
 }
 

clang/lib/Tooling/InterpolatingCompilationDatabase.cpp

   case types::TY_ObjCXX:
   case types::TY_ObjCXXHeader:
     return types::TY_ObjCXX;
+  case types::TY_CUDA:
+  case types::TY_CUDA_DEVICE:
+    return types::TY_CUDA:
   default:
     return types::TY_INVALID;
   }