[Clang] Always pass the detected CUDA path to the linker wrapper

[jhuber6]

Summary:
This patch identifies the CUDA path that clang used and forwards it to
the linker wrapper. This should make sure that we're using a consistent
CUDA path, but the behavior should be the same for normal use.

Most toolchains have a lazy detector for this, which we could
potentially borrow. However, that would require adding a new top-level
accessor to the global toolchain and I wasn't sure if it was worth it
for this, since it's not overly expensive.

[llvmbot]

@llvm/pr-subscribers-clang

Author: Joseph Huber (jhuber6)

Changes

Summary:
This patch identifies the CUDA path that clang used and forwards it to
the linker wrapper. This should make sure that we're using a consistent
CUDA path, but the behavior should be the same for normal use.

Most toolchains have a lazy detector for this, which we could
potentially borrow. However, that would require adding a new top-level
accessor to the global toolchain and I wasn't sure if it was worth it
for this, since it's not overly expensive.

---

Full diff: https://github.com/llvm/llvm-project/pull/142021.diff

1 Files Affected:

• (modified) clang/lib/Driver/ToolChains/Clang.cpp (+12-4)

diff --git a/clang/lib/Driver/ToolChains/Clang.cpp b/clang/lib/Driver/ToolChains/Clang.cpp
index 13842b8cc2870..f72c7e5cb91ae 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -9217,7 +9217,6 @@ void LinkerWrapper::ConstructJob(Compilation &C, const JobAction &JA,
   // compilation job.
   const llvm::DenseSet<unsigned> CompilerOptions{
       OPT_v,
-      OPT_cuda_path_EQ,
       OPT_rocm_path_EQ,
       OPT_O_Group,
       OPT_g_Group,
@@ -9260,6 +9259,18 @@ void LinkerWrapper::ConstructJob(Compilation &C, const JobAction &JA,
     for (auto &I : llvm::make_range(TCRange)) {
       const ToolChain *TC = I.second;
 
+      // All NVPTX targets currently depend on CUDA binary utilities.
+      if (TC->getTriple().isNVPTX()) {
+        // Most toolchains have a cached version of this, but it's not exposed
+        // so we just do the work again.
+        CudaInstallationDetector CudaInstallation(C.getDriver(),
+                                                  TC->getTriple(), Args);
+        if (CudaInstallation.isValid())
+          CmdArgs.push_back(
+              Args.MakeArgString("--device-compiler=" + TC->getTripleString() +
+                                 "=" + CudaInstallation.getInstallPath()));
+      }
+
       // We do not use a bound architecture here so options passed only to a
       // specific architecture via -Xarch_<cpu> will not be forwarded.
       ArgStringList CompilerArgs;
@@ -9314,9 +9325,6 @@ void LinkerWrapper::ConstructJob(Compilation &C, const JobAction &JA,
       Args.MakeArgString("--host-triple=" + getToolChain().getTripleString()));
   if (Args.hasArg(options::OPT_v))
     CmdArgs.push_back("--wrapper-verbose");
-  if (Arg *A = Args.getLastArg(options::OPT_cuda_path_EQ))
-    CmdArgs.push_back(
-        Args.MakeArgString(Twine("--cuda-path=") + A->getValue()));
 
   // Construct the link job so we can wrap around it.
   Linker->ConstructJob(C, JA, Output, Inputs, Args, LinkingOutput);

[llvmbot]

@llvm/pr-subscribers-clang-driver

Author: Joseph Huber (jhuber6)

Changes

Summary:
This patch identifies the CUDA path that clang used and forwards it to
the linker wrapper. This should make sure that we're using a consistent
CUDA path, but the behavior should be the same for normal use.

Most toolchains have a lazy detector for this, which we could
potentially borrow. However, that would require adding a new top-level
accessor to the global toolchain and I wasn't sure if it was worth it
for this, since it's not overly expensive.

---

Full diff: https://github.com/llvm/llvm-project/pull/142021.diff

1 Files Affected:

• (modified) clang/lib/Driver/ToolChains/Clang.cpp (+12-4)

diff --git a/clang/lib/Driver/ToolChains/Clang.cpp b/clang/lib/Driver/ToolChains/Clang.cpp
index 13842b8cc2870..f72c7e5cb91ae 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -9217,7 +9217,6 @@ void LinkerWrapper::ConstructJob(Compilation &C, const JobAction &JA,
   // compilation job.
   const llvm::DenseSet<unsigned> CompilerOptions{
       OPT_v,
-      OPT_cuda_path_EQ,
       OPT_rocm_path_EQ,
       OPT_O_Group,
       OPT_g_Group,
@@ -9260,6 +9259,18 @@ void LinkerWrapper::ConstructJob(Compilation &C, const JobAction &JA,
     for (auto &I : llvm::make_range(TCRange)) {
       const ToolChain *TC = I.second;
 
+      // All NVPTX targets currently depend on CUDA binary utilities.
+      if (TC->getTriple().isNVPTX()) {
+        // Most toolchains have a cached version of this, but it's not exposed
+        // so we just do the work again.
+        CudaInstallationDetector CudaInstallation(C.getDriver(),
+                                                  TC->getTriple(), Args);
+        if (CudaInstallation.isValid())
+          CmdArgs.push_back(
+              Args.MakeArgString("--device-compiler=" + TC->getTripleString() +
+                                 "=" + CudaInstallation.getInstallPath()));
+      }
+
       // We do not use a bound architecture here so options passed only to a
       // specific architecture via -Xarch_<cpu> will not be forwarded.
       ArgStringList CompilerArgs;
@@ -9314,9 +9325,6 @@ void LinkerWrapper::ConstructJob(Compilation &C, const JobAction &JA,
       Args.MakeArgString("--host-triple=" + getToolChain().getTripleString()));
   if (Args.hasArg(options::OPT_v))
     CmdArgs.push_back("--wrapper-verbose");
-  if (Arg *A = Args.getLastArg(options::OPT_cuda_path_EQ))
-    CmdArgs.push_back(
-        Args.MakeArgString(Twine("--cuda-path=") + A->getValue()));
 
   // Construct the link job so we can wrap around it.
   Linker->ConstructJob(C, JA, Output, Inputs, Args, LinkingOutput);