[NVPTX] Add -march=general option to mirror default configuration

[oraluben]

This PR adds -march=generic support for the NVPTX backend. This fulfills a TODO introduced in #79873.

With this PR, users can explicitly request the "default" CUDA architecture, which makes sure that no specific architecture is specified.

This PR does not address any compatibility issues between different CUDA versions.

[github-actions]

Thank you for submitting a Pull Request (PR) to the LLVM Project!

This PR will be automatically labeled and the relevant teams will be
notified.

If you wish to, you can add reviewers by using the "Reviewers" section on this page.

If this is not working for you, it is probably because you do not have write
permissions for the repository. In which case you can instead tag reviewers by
name in a comment by using @ followed by their GitHub username.

If you have received no comments on your PR for a week, you can request a review
by "ping"ing the PR by adding a comment “Ping”. The common courtesy "ping" rate
is once a week. Please remember that you are asking for valuable time from other developers.

If you have further questions, they may be answered by the LLVM GitHub User Guide.

You can also ask questions in a comment on this PR, on the LLVM Discord or on the forums.

[llvmbot]

@llvm/pr-subscribers-clang-driver

@llvm/pr-subscribers-clang

Author: Yichen Yan (oraluben)

Changes

This PR adds -march=generic support for the NVPTX backend. This fulfills a TODO introduced in #79873.

With this PR, users can explicitly request the default CUDA architecture. This default is regularly updated, and the most recent configuration as of commit ab202aa sets it to sm_52. This value is also assumed when no -march option is provided.

This PR does not address any compatibility issues between different CUDA versions.

---

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

2 Files Affected:

• (modified) clang/lib/Driver/ToolChains/Cuda.cpp (+2-2)
• (modified) clang/test/Driver/cuda-cross-compiling.c (+7-2)

diff --git a/clang/lib/Driver/ToolChains/Cuda.cpp b/clang/lib/Driver/ToolChains/Cuda.cpp
index c6007d3cfab864..4cb98f9f28963c 100644
--- a/clang/lib/Driver/ToolChains/Cuda.cpp
+++ b/clang/lib/Driver/ToolChains/Cuda.cpp
@@ -750,8 +750,8 @@ NVPTXToolChain::TranslateArgs(const llvm::opt::DerivedArgList &Args,
     if (!llvm::is_contained(*DAL, A))
       DAL->append(A);
 
-  // TODO: We should accept 'generic' as a valid architecture.
-  if (!DAL->hasArg(options::OPT_march_EQ) && OffloadKind != Action::OFK_None) {
+  if ((!DAL->hasArg(options::OPT_march_EQ) && OffloadKind != Action::OFK_None) ||
+      (DAL->getLastArgValue(options::OPT_march_EQ) == "generic")) {
     DAL->AddJoinedArg(nullptr, Opts.getOption(options::OPT_march_EQ),
                       CudaArchToString(CudaArch::CudaDefault));
   } else if (DAL->getLastArgValue(options::OPT_march_EQ) == "native") {
diff --git a/clang/test/Driver/cuda-cross-compiling.c b/clang/test/Driver/cuda-cross-compiling.c
index 086840accebe7f..e5aeca8300f85c 100644
--- a/clang/test/Driver/cuda-cross-compiling.c
+++ b/clang/test/Driver/cuda-cross-compiling.c
@@ -32,10 +32,15 @@
 //
 // RUN: %clang -target nvptx64-nvidia-cuda -march=sm_61 -### %s 2>&1 \
 // RUN:   | FileCheck -check-prefix=ARGS %s
+// RUN: %clang -target nvptx64-nvidia-cuda -march=generic -### %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=GENERIC %s
 
 //      ARGS: -cc1" "-triple" "nvptx64-nvidia-cuda" "-S" {{.*}} "-target-cpu" "sm_61" "-target-feature" "+ptx{{[0-9]+}}" {{.*}} "-o" "[[PTX:.+]].s"
 // ARGS-NEXT: ptxas{{.*}}"-m64" "-O0" "--gpu-name" "sm_61" "--output-file" "[[CUBIN:.+]].cubin" "[[PTX]].s" "-c"
 // ARGS-NEXT: nvlink{{.*}}"-o" "a.out" "-arch" "sm_61" {{.*}} "[[CUBIN]].cubin"
+//      GENERIC: -cc1" "-triple" "nvptx64-nvidia-cuda" "-S" {{.*}} "-target-cpu" "sm_52" "-target-feature" "+ptx{{[0-9]+}}" {{.*}} "-o" "[[PTX:.+]].s"
+// GENERIC-NEXT: ptxas{{.*}}"-m64" "-O0" "--gpu-name" "sm_52" "--output-file" "[[CUBIN:.+]].cubin" "[[PTX]].s" "-c"
+// GENERIC-NEXT: nvlink{{.*}}"-o" "a.out" "-arch" "sm_52" {{.*}} "[[CUBIN]].cubin"
 
 //
 // Test the generated arguments to the CUDA binary utils when targeting NVPTX. 
@@ -85,6 +90,6 @@
 // MISSING: error: Must pass in an explicit nvptx64 gpu architecture to 'nvlink'
 
 // RUN: %clang -target nvptx64-nvidia-cuda -flto -c %s -### 2>&1 \
-// RUN:   | FileCheck -check-prefix=GENERIC %s
+// RUN:   | FileCheck -check-prefix=COMPILE %s
 
-// GENERIC-NOT: -cc1" "-triple" "nvptx64-nvidia-cuda" {{.*}} "-target-cpu"
+// COMPILE-NOT: -cc1" "-triple" "nvptx64-nvidia-cuda" {{.*}} "-target-cpu"

[github-actions]

✅ With the latest revision this PR passed the C/C++ code formatter.

[oraluben]

@jhuber6 @Artem-B You might want to check if this LGTY :)

[jhuber6]

Thanks for looking at this. When the user compiles with -march=xyz it introduces a lot of subtarget specific metadata intro the output IR. The purpose of the original patch was to keep -target-cpu unset in cases where -march=xyz was not passed in. The expected semantics here is that -march=sm_52 -march=generic will override -march=sm_52 and result in no -target-cpu being set just like if you didn't pass -march at all.

[jhuber6]

FWIW I think you can kind of do this with -march=sm_52 -march= to just set it to empty.

[jhuber6]

LG, thanks for the patch.

[jhuber6]

Thanks, I'll merge it once it passes CI.

[github-actions]

@oraluben Congratulations on having your first Pull Request (PR) merged into the LLVM Project!

Your changes will be combined with recent changes from other authors, then tested
by our build bots. If there is a problem with a build, you may recieve a report in an email or a comment on this PR.

Please check whether problems have been caused by your change specifically, as
the builds can include changes from many authors. It is not uncommon for your
change to be included in a build that fails due to someone else's changes, or
infrastructure issues.

How to do this, and the rest of the post-merge process, is covered in detail here.

If your change does cause a problem, it may be reverted, or you can revert it yourself.
This is a normal part of LLVM development. You can fix your changes and open a new PR to merge them again.

If you don't get any reports, no action is required from you. Your changes are working as expected, well done!