[PATCH] D77670: [CUDA] Add partial support for recent CUDA versions.

Fri Aug 13 14:11:07 PDT 2021

tra added a comment.

In D77670#2944442 <https://reviews.llvm.org/D77670#2944442>, @Hahnfeld wrote:

>> It's also time to bump the default GPU target to something that's supported by the CUDA versions we reasonably expect to see. That should probably be sm_35 as that's probably the oldest GPU platform that's still widely available (e.g. there are tons of them on Google cloud and AWS) and is still supported by all CUDA versions clang accepts.
>
> +1 for at least `sm_35` - that would match recent `nvcc`s, right?

NVCC in 11.4.1 defaults to sm_52 as the oldest non-deprecated GPU. I don't think it's time for clang to go that far as, unlike NVCC, we have to deal with older CUDA versions, too. For us the lowest common denominator for supported CUDA versions and GPUs hardware availability is sm_35.

I could also argue the other way around -- it may make sense to set default GPU to the most recent one supported by all CUDA versions. That will allow clang to compile larger subset of existing CUDA code (new GPUs support more builtins/features the code may rely on.

We could set target GPU to the most recent GPU variant supported by the CUDA version we've found. This, however will mean that the target will change from one system to another, depending on which CUDA version happens to be installed. I think that would be pushing it too far.

In any case, there's no universally good choice as we don't know which GPU the user needs the code for. If our choice is wrong, the app will not run. In practice users do need to specify both CUDA SDK path and the list of GPUs they want to compile for. The defaults, especially the default GPU target, is likely to be wrong more often than not.

> Yeah, the problem was that I didn't have better suggestions either when I wrote the first comment. But maybe now: How about having a "past-the-latest" value in the enum that Clang remembers if it detects a version more recent than it knows about? Then we could have two warnings:
>
> - If we have a "past-the-latest" version, tell the user that Clang has no clue about this version and we assume the `LATEST` version; things might work, but no guarantees.
> - If we have a version that is greater than the latest supported version, emit the current warning and say that support is "best-effort" (or something along that line). In that case, both the detected version and the "assumed" supported version should make sense to the user.

SGTM. I'll send the patch next week and we can discuss the details there.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77670/new/

https://reviews.llvm.org/D77670