[PATCH] D114326: Update the list of CUDA versions up to 11.5

[Artem Belevich via Phabricator via cfe-commits]

tra added a comment.

In D114326#3159122 <https://reviews.llvm.org/D114326#3159122>, @mojca wrote:

> @tra: this is not yet 100% ready since the unit tests are now failing (expecting to find CUDA 8.0).
> I can fix the unit test, but I suppose that someone needs to install additional SDK somewhere into the infrastructure as well?

Clang tests run w/o CUDA SDK itself. We have some mock installations under `Inputs` in the test directory. You may need to adjust both the inputs and the tests to work with your changes.

> In D114326#3158913 <https://reviews.llvm.org/D114326#3158913>, @tra wrote:
>
>> So, yes, you could automatically add linking flags in your example, but it's not feasible to do so for the linking phase in general. It would also introduce inconsistency in clang's linking phase behavior and would lead to questions -- why things work with `clang hello.co`, but not with `clang -c hello.cu; clang hello.o` ?
>
> Please note that I'm a complete newbie to compilers.
> The flag `--cuda-path=` slightly reminds me of the `--framework` keyword on macOS. I'm not behind a mac right now, so please forgive me any typo or wrong paths (it's also not exact since the frameworks are searched for in different folders etc.), below is just a general idea.

Mac is... special in more than one way. "We do it on Mac" alone is not a very strong argument for clang's behavior everywhere else.

My general rule of thumb is that a flag should serve specific purpose and should not duplicate the work of existing flags. 
The way I see it is that CUDA libraries are not any different than any other libraries an app must be linked with and we already have `-L` to tell the linker where to find them.

> What would be cool to me was if `--cuda-path` was also implicitly adding the `-L` flag, so that the following would work:
>
>   clang++ --cuda-path=/usr/local/cuda-11.5 -l cudart hello.cu
>   clang++ --cuda-path=/usr/local/cuda-11.5 -l cudart hello.o
>
> I don't know whether it would be acceptable to add (the default) cuda library path to the linker though.

TBH, I don't see much of a benefit over `clang++ -L/usr/local/cuda-11.5/lib64 -l cudart hello.o`, and I do see a few downsides in form of implicit `-L` interfering with explicit `-L`. E.g. will a user need to consider where on the command line they place `--cuda-path` relative to `-L`/`-l` now? Where (or whether?) will the linker path be added if clang is run w/o `--cuda-path`? How many users will be surprised by magically materialized linking paths (that they were not aware of) interfering with explicitly specified `-L`? E.g. user runs `clang -L/non/default/cuda/lib64` and the implicitly added `-L` picks the library from the auto-found CUDA location, instead of the one specified by the user. Etc.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114326