[Bug target/104758] New: [nvptx] sm_30 support

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104758

            Bug ID: 104758
           Summary: [nvptx] sm_30 support
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

I.

Let's start out with some history.

gcc-5, gcc-6, gcc-7, gcc-8:
only sm_30 support

gcc-9, gcc-10:
sm_30 + sm_35 support, default: sm_30

gcc-11:
sm_30 + sm_35 support, default: sm_35 

II.

The default was moved from sm_30 to sm_35 (PR97348), because recent CUDA
dropped support for sm_30, which inhibited the build (when build with CUDA bin
in the path).

That left the possibility open to build some program still for sm_30, but it
might include library code that would be build for sm_35, so building a pure
sm_30 exec was no longer guaranteed.

And if we build a program for sm_30, but also get sm_35 code, and try to
execute on an sm_30 board, we run into trouble.

Well, unless one would rebuild gcc with the default set back to sm_30, without
the CUDA in the path.

Something that might address this without requiring a gcc rebuild would be to
add a sm_30 multilib dimension:
...
diff --git a/gcc/config/nvptx/t-nvptx b/gcc/config/nvptx/t-nvptx
index f17fc9c19aac..a726a4ae7419 100644
--- a/gcc/config/nvptx/t-nvptx
+++ b/gcc/config/nvptx/t-nvptx
@@ -30,4 +30,4 @@ s-nvptx-gen-opt: $(srcdir)/config/nvptx/nvptx-sm.def
          tmp-nvptx-gen.opt $(srcdir)/config/nvptx/nvptx-gen.opt
        $(STAMP) s-nvptx-gen-opt

-MULTILIB_OPTIONS = mgomp
+MULTILIB_OPTIONS = mgomp misa=sm_30
...

But that brings back the same problem that we tried to avoid by changing the
default: it no longer builds with recent CUDA.

With f.i. sm_30 triggering -Wa,--no-verify, we could work around the CUDA
problem:
...
diff --git a/gcc/config/nvptx/nvptx.h b/gcc/config/nvptx/nvptx.h
index 4ab412bc7d8e..3ca22a595d20 100644
--- a/gcc/config/nvptx/nvptx.h
+++ b/gcc/config/nvptx/nvptx.h
@@ -32,7 +32,7 @@
 /* Default needs to be in sync with default for misa in nvptx.opt.
    We add a default here to work around a hard-coded sm_30 default in
    nvptx-as.  */
-#define ASM_SPEC "%{misa=*:-m %*; :-m sm_35}"
+#define ASM_SPEC "%{misa=*:-m %*; :-m sm_35}%{misa=sm_30:--no-verify}"

 #define TARGET_CPU_CPP_BUILTINS() nvptx_cpu_cpp_builtins ()

...

We could do something similar by making nvptx-as.c detect the "SM version
specified by .target is higher than default SM version assumed" problem and not
error out, perhaps issue a warning, or deal with this at nvptx-tools configure
time, similar to how that is done for ptxas unavailability.

Likewise, we could deal with this at gcc configure time.

An alternative for:
...
MULTILIB_OPTIONS = mgomp misa=sm_30
...
could be:
...
MULTILIB_EXTRA_OPTS = misa=sm_30
...
In other words, we keep default sm_35, but the default multilib arch is set
back to sm_30.


III.

For the ptx isa version, we had:

gcc-5, gcc-6, gcc-7, gcc-8, gcc-9, gcc-10, gcc-11:
3.1 support

gcc-12:
3.1, 6.0, 6.3, 7.0 support, default: picked based on sm_xx, with minimum of 6.0

IV.

So, even with:
...
MULTILIB_EXTRA_OPTS = misa=sm_30
...
we have in libgcc:
...
.version 6.0
.target sm_30
...
which means we're excluding older drivers that used to work with .version 3.1.

We can fix that using:
...
MULTILIB_EXTRA_OPTS = misa=sm_30 mptx=3.1
...