Building libomptarget and its other components, such as deviceRTLs,
plugins, requires LLVM or other functionalities in compiler. They're currently
not handled very well. This patch (or series of patches in the near future)
refines the whole detection code. The basic idea is, if libomptarget cannot be
built due to any reason, it should not block the configuration or compilation of
the whole OpenMP project. Not everyone wants target offloading. This patch is the
first patch to clean logics for libomptarget. It simply does one thing: if
the condition is not met, simply skip libomptarget.
Details
- Reviewers
jdoerfert JonChesterfield
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
openmp/libomptarget/plugins/amdgpu/CMakeLists.txt | ||
---|---|---|
33 | This lines of code are removed because it can only reach here if the requirement is met. |
I don't understand the control flow here. It looks like OPENMP_ENABLE_LIBOMPTARGET = ON, as before, but we now check for LLVM=12 on one path and not on another.
I think you sent an email suggesting we should test whether the compiler can actually build the plugin. LLVM==12 probably isn't a sufficiently robust way to do that.
Can cmake handle passing a pre-made c++ file to the compiler to test if it can build? I'm thinking we could craft one that used variant, various intrinsics etc that are representative of the gpu code runtime.
So libomptarget is still enabled by default, but it exits immediately if any check doesn’t pass. LLVM 12 here is just to make sure that APIs we’re using is the one we want. My system has LLVM 8. CMake can detect it and use it, but APIs have been changed so it cannot pass compilation.
I think you sent an email suggesting we should test whether the compiler can actually build the plugin. LLVM==12 probably isn't a sufficiently robust way to do that.
Yes, my previous comment actually contains two points, one of which is about the test of compiler for deviceRTLs (which will be covered in another patches), and another one is this. I encountered issues when I just wanted to debug something wrong in libomp. So I just build OpenMP with GCC standalone.
Can cmake handle passing a pre-made c++ file to the compiler to test if it can build? I'm thinking we could craft one that used variant, various intrinsics etc that are representative of the gpu code runtime.
Yes, that’s what I’m gonna do: write a tiny test case and check if the compiler can compile it.
openmp/libomptarget/CMakeLists.txt | ||
---|---|---|
47 | Could you unset cached variable OPENMP_ENABLE_LIBOMPTARGET (in a proper place)? Just to keep CMakeCached consistent. Since OPENMP_ENABLE_LIBOMPTARGET is not in the current CMakeLists.txt, the unset probably needs to be at openmp/CMakeLists.txt |
openmp/libomptarget/CMakeLists.txt | ||
---|---|---|
47 | I feel that would be not a good direction. IMO, OPENMP_ENABLE_LIBOMPTARGET is just an option which presumably should be set by users. Its only functionality is to tell CMake whether we need to involve libomptarget. As for whether libomptarget can be built successfully, it's out of its control. Even if due to some reasons it is not built, as long as users don't set it to OFF, libomptarget still needs to be involved. For example, after users revolve issues found, it just needs to reconfigure the project instead set the variable to ON explicitly. |
Could you unset cached variable OPENMP_ENABLE_LIBOMPTARGET (in a proper place)? Just to keep CMakeCached consistent.
Since OPENMP_ENABLE_LIBOMPTARGET is not in the current CMakeLists.txt, the unset probably needs to be at openmp/CMakeLists.txt
and the current CMakeLists.txt needs to set a return value signalling libomptarget not being built.