as: Deal with CUDA 11.0, "Support for Kepler 'sm_30' and 'sm_32' architecture based products is dropped"

[tschwinge]

This resolves #30 "[RFC] Handle sm_* which is no longer supported by CUDA / ptxas exec check or configure check?".

@vries, what do you think about this one? With that installed, we may then revert GCC commit bf4832d6fa817f66009f100a9cd68953062add7d "[nvptx] Fix ASM_SPEC workaround for sm_30", and GCC commit 12fa7641ceed9c9139e2ea7b62c11f3dc5b6f6f4 "[nvptx] Use --no-verify for sm_30".

[tob2]

I dislike the silent, unconditional overriding of the .target handling. I think that at least with -v there should be warning (→ PR #31)

• On the con side, this patch disables sm_30 checking by only assemblying with sm_35.
• On the pro side, this patch allows for some checks with newer CUDA versions (>= 11.0) for sm_30 and sm_32 (sm_32 not used on the GCC side), instead of aborting with an error (→ current state) or not verifying without --verify (→ PR Issue 30: Ignore not-supported sm_* error without --verify #31).

Thus, I think this patch is okay (with a -v warning), but it does not replace the PR #31.

@vries – thoughts on this/Thomas' patch and on my comment?

[tob2]

See also https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593057.html related to this patch:
"Re: [committed][nvptx] Fix ASM_SPEC workaround for sm_30"

[vries]

I dislike the silent, unconditional overriding of the .target handling. I think that at least with -v there should be warning (→ PR #31)

Hm, so what would this warning look like? Something like this:
...
warning: Using sm_35 to verify sm_30/sm_32 code
...

I suppose a warning would suggest to an unsuspecting user that some action may need to be taken, which is not the case (because the overriding is unconditional), so perhaps just an informative message, like a note:
...
note: Using sm_35 to verify sm_30/sm_32 code
...

[tob2]

I dislike the silent, unconditional overriding of the .target handling. I think that at least with -v there should be warning (→ PR #31)

(...)

so perhaps just an informative message, like a note: ... note: Using sm_35 to verify sm_30/sm_32 code ...

Fine with me, but maybe "note: using sm_35 to verify sm_30/sm_32 code for CUDA-compatibility reasons" or something like that which gives at least a hint why that's necessary.

In the issue itself, #30, a variant of using PTX Compiler APIs instead of ptxas is discussed. Thus, the message could be adapted accordingly, when knowing for sure which sm_xx is actually supported.

[tschwinge]

The focus for current nvptx-tools should be to make things work best with current GCC and CUDA versions, and the proposed method (whether it's in GCC or nvptx-tools) seems like an acceptable "degradation" to me. (I'm essentially just moving @vries' GCC-level "workaround: verify using sm_35 when misa=sm_30 is specified" from GCC into nvptx-tools.)

I dislike the silent, unconditional overriding of the .target handling. I think that at least with -v there should be warning

As @vries also said, let's call this a diagnostic/message/note instead of a warning. I'll look into implementing that, but it has to wait until after my upcoming vacations.

• On the con side, this patch disables sm_30 checking by only assemblying with sm_35.

I'm not sure I understand what exactly you're implying with "patch disables sm_30 checking by only assembling with sm_35": per my understanding, given .target sm_30 input code, ptxas would still check the PTX code for .target sm_30 validity -- just the code generation is then done for sm_35, but that's not very relevant for us, because we discard that anyway.

Thus, the following proposed wording:

maybe "note: using sm_35 to verify sm_30/sm_32 code for CUDA-compatibility reasons" or something like that which gives at least a hint why that's necessary.

... may also not completely true/clear, or maybe even confusing?