This is an archive of the discontinued LLVM Phabricator instance.

[OpenMP][CMake] Pass --cuda-path to regression tests.
ClosedPublic

Authored by Meinersbur on Apr 25 2021, 3:52 PM.

Details

Summary

The OpenMP runtime can be compiled using a CUDA installed at non-default location with the -DCUDA_TOOLKIT_ROOT_DIR setting. However, check-openmp will fail afterwards because Clang needs to know where to find the CUDA headers.

Fix by passing -cuda-path to Clang using the value of CUDA_TOOLKIT_ROOT_DIR which has been determined by CMake. Also set LD_LIBRARY_PATH such that it can find the cuda runtime when executing. This will ensure that the regression test do not depend on the current environment, but use the environment it was configured for.

See the current builder and the build with this patch applied.

Diff Detail

Event Timeline

Meinersbur created this revision.Apr 25 2021, 3:52 PM
Meinersbur requested review of this revision.Apr 25 2021, 3:52 PM
tianshilei1992 added inline comments.Apr 25 2021, 4:40 PM
openmp/libomptarget/deviceRTLs/nvptx/test/lit.site.cfg.in
8

This variable will not be set by CMake based on CMake document.

  • Define CUDA_LIBDIR for lit.site.cfg
Meinersbur marked an inline comment as done.Apr 25 2021, 6:09 PM
Meinersbur added inline comments.
openmp/libomptarget/deviceRTLs/nvptx/test/lit.site.cfg.in
8

Thanks.

tianshilei1992 accepted this revision.Apr 26 2021, 11:32 AM

LGTM. Thanks!

This revision is now accepted and ready to land.Apr 26 2021, 11:32 AM

The ld_library_path requirement is nasty. We should burn rpath/runpath into the cuda plugin (and probably also corresponding rpath/runpath into executables so they can find the openmp runtime libraries)

On our site, the dependencies are not necessarily found in the same directory when moving from build system to compute system. So, for production use I actually prefer LD_LIBRARY_PATH & CO, which are managed by the environment-modules system.

Meinersbur marked an inline comment as done.Apr 26 2021, 3:56 PM

The ld_library_path requirement is nasty. We should burn rpath/runpath into the cuda plugin (and probably also corresponding rpath/runpath into executables so they can find the openmp runtime libraries)

What is so nasty about it? It is already sets a couple of other library paths. rpath unfortunately is less portable.

Does someone know why in one place it is prepend_library_path, but append_dynamic_library_path in the other? I think all libraries should be pre-pended, in order to take precedence over other system-installed libraries, such as in paths set by module load cuda/module load llvm.

The ld_library_path requirement is nasty. We should burn rpath/runpath into the cuda plugin (and probably also corresponding rpath/runpath into executables so they can find the openmp runtime libraries)

What is so nasty about it? It is already sets a couple of other library paths. rpath unfortunately is less portable.

It leaks an internal detail to the user. Someone builds their application with openmp enabled, goes to run it, and it fails because it can't find the libraries that clang implicitly created dependencies on, even though clang knows where said dependencies are. Defaulting to the openmp that ships with clang removes that hurdle and still lets people override it with LD_LIBRARY_PATH if they wish (iirc it's RUNPATH that allows that override and rpath that doesn't).

As far as I know rpath works everywhere, but where it doesn't, those users can continue doing whatever they do today to find the libraries.

It leaks an internal detail to the user.

It's only used during testing by llvm-lit whether the built was successful.

Someone builds their application with openmp enabled, goes to run it, and it fails because it can't find the libraries that clang implicitly created dependencies on, even though clang knows where said dependencies are.

Again, no consequence to the end-user of clang. To compile a program, the user will have to pass --cuda-path and/or the environment variables manually (or use module load).

Or is your concern that when check-openmp succeeds, the user might think that they do not have to point to a CUDA installation anymore?

Defaulting to the openmp that ships with clang

This is for the search path of libdevice.so and cudart.so, not libomp.so nor libomptarget.so.

Ah, I have confused this with needing to set LD_LIBRARY_PATH to find libomp.so when running an application, which may have been fixed somewhat recently. The tests using environment variables set by cmake to find cuda seems fine.

Needing to pass --cuda-path in the probably common case of a single cuda install in one of a few likely destinations is inconvenient but probably OK in practice. Iirc there's a rocm-path with similar properties, though I think that has some defaults it looks in when not specified.

Ah, I have confused this with needing to set LD_LIBRARY_PATH to find libomp.so when running an application, which may have been fixed somewhat recently. The tests using environment variables set by cmake to find cuda seems fine.

Actually LD_LIBRARY_PATH is indeed also set to find libomp.so and libomptarget.so in test. You can find it just a few lines above the code change in openmp/libomptarget/test/lit.cfg. However I don't think it's a problem, as long as they're prepended.

This revision was landed with ongoing or failed builds.Apr 27 2021, 2:29 PM
This revision was automatically updated to reflect the committed changes.