[OpenMP] Fix runtimes default build#149871
Conversation
Meinersbur
changed the title
llvmbot
added
cmake
Co-authored-by: Joseph Huber <huberjn@outlook.com>
The default build of openmp (`cmake -S <llvm-project>/runtimes -DLLVM_ENABLE_RUNTIMES=openmp`) current fails with ``` CMake Error at /home/meinersbur/src/llvm/flangrt/_src/cmake/Modules/GetClangResourceDir.cmake:17 (string): string sub-command REGEX, mode MATCH needs at least 5 arguments total to command. Call Stack (most recent call first): /home/meinersbur/src/llvm/flangrt/_src/openmp/CMakeLists.txt:126 (get_clang_resource_dir) ``` The reason is that because it is not a bootstrapping-build, the clang resource dir that it intends to write files such as `omp-tools.h` into, is unavailable. Using the Clang resource dir for writing files is conceptually broken, as that dir might be located in `/usr/lib/clang/<version>/`. Writing to it is only intended in bootstrapping builds where Clang is built alongside openmp. This patch unifies the identification of being in a bootstrapping built. The same `LLVM_TREE_AVAILABLE` definition is going to be used in llvm#137828. No reason for each runtime to define its own.
|
Hi @Meinersbur This commit has broken 3-stage AArch64 builds. Without this build, We use 3-stage builds quite often; I appreciate the recommendation or a fix here soon. Here is the simple code: I believe as this commit has changed the location of |
|
@madhur13490 can you provide information about the three stages (i.e., relevant cmake flags for all stages like llvm-projects/runtime, flags to customize openmp build/install paths)? |
|
|
||
| # The generated headers will be placed in clang's resource directory if present. | ||
| if(OPENMP_STANDALONE_BUILD OR NOT LLVM_RUNTIMES_BUILD) | ||
| if(NOT LLVM_TREE_AVAILABLE) |
There was a problem hiding this comment.
When building openmp as llvm project, LLVM_TREE_AVAILABLE is undefined, so the wrong branch will be used
There was a problem hiding this comment.
I only considered the standalone build when LLVM_TREE_AVAILABLE being undefined just means means the LLVM tree is indeed not available. Will create a fix.
Note that that build mode is deprecated. #124014.
We use standard 3-stage LTO-PGO-BOLT builds, which primarily use https://github.com/llvm/llvm-project/blob/main/clang/cmake/caches/BOLT-PGO.cmake. You can find top-level community doc at https://llvm.org/docs/AdvancedBuilds.html |
This fits to my in code comment above.
These documents don't include OpenMP in their builds. |
via |
I assume The openmp build must not write outside its own build tree. Doing so causes countless problems such as conflicting versions of
This looks like you are invoking clang from the build directory. Either switch to a bootstrapping-build of openmp, or install both Clang and openmp into the same CMAKE_INSTALL_PREFIX and launch Clang from there. |
In this case the Clang build tree and the openmp build tree are identical. Fixed in #151117. Note that this build mode is deprecated since #136314. Consider moving to a runtimes build. According to the warning message added in #136314, that build mode should already have been removed. |
Thanks for all the help. We switched to |
Remove all the CMake code for openmp standalone builds. Standalone builds have been superseded by the runtimes default build (also sometimes called the standalone runtimes build). The runtimes default build can be thought of a standalone build with the standalone boilerplate contained in <llvm-project>/runtimes/CMakeLists.txt. There is no need for each runtime to contain the same boilerplate code again. Builds still using the standalone build via ```sh cmake -S <llvm-project>/openmp ... ``` can switch over to the runtimes default build using ```sh cmake -S <llvm-project>/runtimes -DLLVM_ENABLE_RUNTIMES=openmp ... ``` Options that were valid for the standalone build are also valid for default runtimes build, unless handled only in `if (OPENMP_STANDALONE_BUILD)` regions. The existence of both, standalone builds and runtime default builds, easily leads to confusion such as fixed in #149871. A non-standalone build does not mean that it is built as part of a bootstrapping-build of LLVM inside the `runtimes/runtimes-bins` directory, nor does it mean that the compiler is necessarily Clang. Some of the remaining code may have been written with that assumption. However, the purpose of this patch is to only remove the standalone build functionality.
This reapplies #149878 Remove all the CMake code for openmp standalone builds. Standalone builds have been superseded by the runtimes default build (also sometimes called the standalone runtimes build). The runtimes default build can be thought of a standalone build with the standalone boilerplate contained in <llvm-project>/runtimes/CMakeLists.txt. There is no need for each runtime to contain the same boilerplate code again. Builds still using the standalone build via ```sh cmake -S <llvm-project>/openmp ... ``` can switch over to the runtimes default build using ```sh cmake -S <llvm-project>/runtimes -DLLVM_ENABLE_RUNTIMES=openmp ... ``` Options that were valid for the standalone build are also valid for default runtimes build, unless handled only in `if (OPENMP_STANDALONE_BUILD)` regions. The existence of both, standalone builds and runtime default builds, easily leads to confusion such as fixed in #149871. A non-standalone build does not mean that it is built as part of a bootstrapping-build of LLVM inside the `runtimes/runtimes-bins` directory, nor does it mean that the compiler is necessarily Clang. Some of the remaining code may have been written with that assumption. However, the purpose of this patch is to only remove the standalone build functionality.
Remove all the CMake code for openmp standalone builds. Standalone builds have been superseded by the runtimes default build (also sometimes called the standalone runtimes build). The runtimes default build can be thought of a standalone build with the standalone boilerplate contained in <llvm-project>/runtimes/CMakeLists.txt. There is no need for each runtime to contain the same boilerplate code again. Builds still using the standalone build via ```sh cmake -S <llvm-project>/openmp ... ``` can switch over to the runtimes default build using ```sh cmake -S <llvm-project>/runtimes -DLLVM_ENABLE_RUNTIMES=openmp ... ``` Options that were valid for the standalone build are also valid for default runtimes build, unless handled only in `if (OPENMP_STANDALONE_BUILD)` regions. The existence of both, standalone builds and runtime default builds, easily leads to confusion such as fixed in llvm#149871. A non-standalone build does not mean that it is built as part of a bootstrapping-build of LLVM inside the `runtimes/runtimes-bins` directory, nor does it mean that the compiler is necessarily Clang. Some of the remaining code may have been written with that assumption. However, the purpose of this patch is to only remove the standalone build functionality.
5 participants
The default build of openmp (
cmake -S <llvm-project>/runtimes -DLLVM_ENABLE_RUNTIMES=openmp) currently fails withThe reason is that because it is not a bootstrapping-build, the clang resource dir that it intends to write files such as
omp-tools.hinto, is unavailable. Using the Clang resource dir for writing files is conceptually broken, as that dir might be located in/usr/lib/clang/<version>/. Writing to it is only intended in bootstrapping builds where Clang is built alongside openmp.This patch unifies the identification of being in a bootstrapping built. The same
LLVM_TREE_AVAILABLEdefinition is going to be used in #137828. No reason for each runtime to define its own.