argentite added inline comments.
================
Comment at: clang/unittests/Interpreter/InteractiveCudaTest.cpp:92
+ std::unique_ptr<clang::Interpreter> Interp = createInterpreter();
+ auto Err = Interp->LoadDynamicLibrary("libcudart.so");
+ if (Err) { // CUDA runtime is not installed/usable, cannot continue testing
----------------
tra wrote:
> argentite wrote:
> > tra wrote:
> > > This could be a bit of a problem.
> > >
> > > There may be multiple CUDA SDK versions that may be installed on a system
> > > at any given time and the libcudart.so you pick here may not be the one
> > > you want.
> > > E.g it may be from a recent CUDA version which is not supported by NVIDIA
> > > drivers yet.
> > >
> > > I think you may need a way to let the user override CUDA SDK (or
> > > libcudart.so) location explicitly. I guess they could do that via
> > > LD_LIBRARY_PATH, but for the CUDA compilation in general, knowing CUDA
> > > SDK path is essential, as it does affect various compilation options set
> > > by the driver.
> > >
> > Yes, this probably would be an issue. It is currently possible to override
> > the CUDA path with a command line argument in clang-repl. But I am not sure
> > what we can do inside a test.
> To me it looks like CUDA location should be detected/set at the configuration
> time and then propagated to the individual tests that need that info.
> CMake has cuda detection mechanisms that could be used for that purpose.
> They are a bit of a pain to use in practice (I'm still not sure what's the
> reliable way to do it), but it's as close to the 'standard' way of doing it
> as we have at the moment.
> I believe libc and mlir subtrees in LLVM are already using this mechanism.
> E.g
> https://github.com/llvm/llvm-project/blob/main/libc/utils/gpu/loader/CMakeLists.txt#L16
This version uses CMake to detect the paths as in the example above. I guess
this would tie the test to the build system but it should probably be fine for
most cases. Unfortunately I don't think we can use the same trick for
determining the path in ClangREPL because the interpreter is likely to run on a
different system.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D151904/new/
https://reviews.llvm.org/D151904
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
