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