@llvm/pr-subscribers-clang-driver

@llvm/pr-subscribers-clang

Author: Artem Belevich (Artem-B)

diff --git a/clang/lib/Driver/ToolChains/Clang.cpp b/clang/lib/Driver/ToolChains/Clang.cpp
index 43a92adbef64ba8..fb90fcd033b1ac3 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -5743,6 +5743,10 @@ void Clang::ConstructJob(Compilation &C, const JobAction &JA,
     } else if (Triple.getArch() == llvm::Triple::x86_64) {
       Ok = llvm::is_contained({"small", "kernel", "medium", "large", "tiny"},
                               CM);
+    } else if (Triple.isNVPTX()) {
+      // NVPTX does not care about the code model and will accept whatever works
+      // for the host.
+      Ok = true;
     }
     if (Ok) {
       CmdArgs.push_back(Args.MakeArgString("-mcmodel=" + CM));

The current filtering mechanism is gross. We have code that does the following error checking for a lot of options and there are more and more of them. It is nearly infeasible to enumerate them.

if (!Triple.isXXX()) { err_unsupported_opt_for_target  } else handle

When such an option is used in clang++ --cuda-path=/usr/local/cuda -x cu /dev/null -c -nocudainc -nocudalib $option, we will get an error for NVPTX.

-mcmodel= turned out to be an issue just because we add this option globally.

https://reviews.llvm.org/D105226 introduced a special case to exclude NVPTX for -fbasic-block-sections=, so this has a precedent, but we should figure out a way to handle the target-specific options in a more elegant way.

I do not know whether we should use something similar to -fembed-bitcode's list.

should this have had a test? I'm trying to do the same thing for -mlarge-data-threshold and am trying to find an appropriate place to add a test

edit: actually #77958 seems to have worked around this