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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
