This patch adds an additional flag to the OpenMP device offloading toolchain to link in the runtime library bitcode.
Details
- Reviewers
Hahnfeld ABataev carlo.bertolli caomhin grokos hfinkel - Commits
- rG0d5aa84ad91d: [OpenMP] Add flag for linking runtime bitcode library
rG148046c11b15: [OpenMP] Add flag for linking runtime bitcode library
rC327460: [OpenMP] Add flag for linking runtime bitcode library
rL327460: [OpenMP] Add flag for linking runtime bitcode library
rL327438: [OpenMP] Add flag for linking runtime bitcode library
rC327438: [OpenMP] Add flag for linking runtime bitcode library
Diff Detail
- Repository
- rL LLVM
Event Timeline
lib/Driver/ToolChains/Cuda.cpp | ||
---|---|---|
559 ↗ | (On Diff #133877) | Should we be more specific when it comes to the name of the missing bc file and include the sm version? E.g. we may have libomptarget-nvptx-sm35.bc in LIBRARY_PATH but the driver needs libomptarget-nvptx-sm60.bc. If the user gets a general missing libomptarget-nvptx.bc message, it may not be clear what the problem is. |
test/Driver/unix-openmp-offload-gpu.c | ||
---|---|---|
15 ↗ | (On Diff #134235) | I don't see how that solves the problem of using /tmp?!? |
test/Driver/openmp-offload-gpu.c | ||
---|---|---|
150 ↗ | (On Diff #133919) | I don't think this would have worked since I need to create a file with a specific name in a folder somewhere and the separator is OS specific. I moved the test to a new file where I limit OS to linux. |
test/Driver/openmp-offload-gpu.c | ||
---|---|---|
150 ↗ | (On Diff #133919) | I'm pretty sure lit takes care of this, there are a lot of other tests that do so. |
test/Driver/unix-openmp-offload-gpu.c | ||
15 ↗ | (On Diff #134235) | (Interesting that this works with %t, the documentation mentions %T for a directory. But as other test cases do the same...) |
test/Driver/unix-openmp-offload-gpu.c | ||
---|---|---|
15 ↗ | (On Diff #134235) | %T works too I just tried it. Any preference as to which one to use? |
test/Driver/unix-openmp-offload-gpu.c | ||
---|---|---|
15 ↗ | (On Diff #134235) | No not really. The Clang tests aren't consistent so I don't think it matters... |
I'm still not sure we can't run this test on Windows. I think lots of other tests use touch, even some specific to Windows...
Let me know what you'd like me to do. I can add the test back. I do see other tests not worrying about this so maybe I can do the same here...
To make it clear, I think doing all checks in openmp-offload-gpu.c increases coverage and will work as other tests show.
Looking more closely at the patch, this doesn't seem to look into the lib / lib64 next to the compiler. I'm not sure if LIBRARY_PATH is set for every installation, so I think we should add this one to catch the obvious case. This probably needs some attention for the tests because they'll find the just-built libraries...
lib/Driver/ToolChains/Cuda.cpp | ||
---|---|---|
536–542 ↗ | (On Diff #134295) | tools::addDirectoryList uses StringRef::find, I'm not sure if StringRef::split creates real copies of the string... |
The contract with the user us that the .bc lib needs to be in LIBRARY_PATH, this is what we require today. Inlining of the runtime is not essential for correctness.
lib/Driver/ToolChains/Cuda.cpp | ||
---|---|---|
536–542 ↗ | (On Diff #134295) | What is your suggestion? |
And I don't think this is clever. The compiler should always try to automatically find the files it needs and looking in the lib directory next to the compiler installation isn't hard in that case and a guess that will meet 99% of deployments.
lib/Driver/ToolChains/Cuda.cpp | ||
---|---|---|
536–542 ↗ | (On Diff #134295) | IMO you should use whatever existing code does, in that case StringRef::find. |
lib/Driver/ToolChains/Cuda.cpp | ||
---|---|---|
591 ↗ | (On Diff #137203) | Maybe just LibraryPaths.emplace_back(DefaultLibPath);? |
598 ↗ | (On Diff #137203) | Wow, never do such things! This is a pointer to non-null terminated string. const char EnvPathSeparatorStr[] = {EnvPathSeparator, '\0'}; And use this array as a separator. |
lib/Driver/ToolChains/Cuda.cpp | ||
---|---|---|
536–542 ↗ | (On Diff #134295) | Is this comment still relevant in the light of the most recent changes? |
lib/Driver/ToolChains/Cuda.cpp | ||
---|---|---|
536–542 ↗ | (On Diff #134295) | Probably not (although the code is now completely different from tools::addDirectoryList) |
lib/Driver/ToolChains/Cuda.cpp | ||
---|---|---|
536–542 ↗ | (On Diff #134295) | Gotcha, do let me know if you see any other issue with this version of the code. I will mark this one as done for now. |
test/Driver/openmp-offload-gpu.c | ||
---|---|---|
150 ↗ | (On Diff #137233) | I'm also in favour of this approach. On some systems /tmp is not accessible and the regression test fails. |
test/Driver/openmp-offload-gpu.c | ||
---|---|---|
150 ↗ | (On Diff #137233) | This test doesn't (and shouldn't!) use /tmp. The build directory and %T are always writable (if not, you have different issues on your system). Btw you need to pay attention that the driver now finds files next to the compiler directory. You may want to make sure that the test always passes / doesn't fail for wrong reasons. |
test/Driver/openmp-offload-gpu.c | ||
---|---|---|
150 ↗ | (On Diff #137233) | (My comment was related to @grokos, the usage of %T and temporarily creating the bc lib. The current approach with %S/Inputs is much cleaner, but you need to create a subdirectory as everbody else did.) Then you need to find a way to stop this. There already are some flags to change the sysroot etc., but I don't know if the influence what you use in this patch. In the worst case, you need to add a new flag to disable DefaultLibPath and use it in the tests. You can't propose to commit a test that is known to break (although I acknowledge that libomptarget-nvptx-sm_20.bc will probably never exist). |
Fix test.
test/Driver/openmp-offload-gpu.c | ||
---|---|---|
150 ↗ | (On Diff #137233) | I created a lib folder where the empty .bc is present: %S/Inputs/lib Good point. sm_20.bc cannot be created since libomptarget requires sm_30 at least which means that there can never be an sm_20 in the DefaultLibPath folder so the only way to find it is to follow LIBRARY_PATH. This resolves the issue. |
test/Driver/openmp-offload-gpu.c | ||
---|---|---|
150 ↗ | (On Diff #137233) | Yes, and everybody else creates subdirectories with names that explain what they contain: CUDA, debian, mingw etc. You should pay more attention to follow a common style when already established. Relying that sm_20 will never be there is maybe not the cleanest solution but should work here. I'm fine unless somebody else objects. |
Improve test robustness for the case when CUDA libdevice cannot be found.
Check that the warning is not emitted when the bc lib is found.