[OpenMP] Disable LTO build of libomptarget and plugins by default.

[Meinersbur]

CheckIPOSupported is used to test for working LTO since #74520. However, before CMake 3.24 this will test the default linker and ignore options such as LLVM_ENABLE_LLD. As a result, CMake would test whether LTO works with the default linker but builds with another one. In a typical scenario, libomptarget is compiled with the in-tree Clang, but linked with ld.gold, which requires the LLVMgold plugin, when it actually would work with the lld linker (or also fail because the system lld is too old to understand opaque pointers). Using gcc as the compiler would pass the test, but fail when linking with lld since does not understand gcc's LTO format.

Disable LTO by default for now since automatic detection causes too many problems. It causes the openmp-offload-cuda-project buildbot (https://lab.llvm.org/staging/#/builders/151) to fail and LLVM_ENABLE_RUNTIMES=openmp builds will have it implicitly disabled in the vast majority of system configurations anyway.

[jhuber6]

I think this also made the projects build fail at some point.

[jhuber6]

I'm wondering if we shouldn't just go off of LLVM_ENABLE_LTO. But I guess the intention was to have LTO be the default. Given CMake's differences on this which I wasn't aware of, it might just be better to check the regular check_if_supported things for -flto=full.

[jhuber6]

Let's just turn this off for now as it causes some other problems and revisit it after the move.

[Meinersbur]

I'm wondering if we shouldn't just go off of LLVM_ENABLE_LTO. But I guess the intention was to have LTO be the default.

I assume Johannes had an intention behind, such that the runtime library performance is more critical than compiler performance. If so, it should apply on every runtime including libcxx. Maybe those are too big such that the llvm-project build time become too long to be switched on by default? If not, then I agree the setting should be handled for all runtimes.

Given CMake's differences on this which I wasn't aware of, it might just be better to check the regular check_if_supported things for -flto=full.

If by that you mean check for that the flag is accepted by the compiler (check_compiler_flag), it's not sufficient. As mentioned there are lots of reasons why the compiler would accept the flag, but linking fails. Some reasons:

• ld.bfd does not support LTO at all (AFAIK)
• mold does not support LTO at all (AFAIK)
• ld.gold, but no LLVMgold plugin available
• ld.lld or LLVMgold, but based on a too old version of LLVM (for me, Ubuntu's lld-14 complains about opaque pointers)
• Using gcc -flto, which only understood by ld.gold.

gcc and the most recent Clang also support -ffat-lto-objects which allows the linker to fall back to a non-LTO build, at the cost of build-time.

Note that the issue has been fixed in CMake 3.24, but even if you have CMake 3.24 or newer, it intentionally uses the old behavior for compatibility unless we use cmake_minimum_required(VERSION 3.24) (Current llvm uses 3.20.0).

[jhuber6]

There's a reasonable chance we could somewhat enforce -fuse-ld=lld on a runtimes barrier. Runtime performance is definitely more important than compiler performance, so perhaps it would be prudent to bring up a wider discussion about building runtimes with LTO.