[Openmp-commits] [openmp] [OpenMP] Disable LTO build of libomptarget and plugins by default. (PR #79387)

[Michael Kruse via Openmp-commits]

Meinersbur wrote:

> 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-proejct 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](https://github.com/rui314/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.

Note that the issue has been fixed in [CMake 3.24](https://cmake.org/cmake/help/latest/policy/CMP0138.html#policy:CMP0138), but even if you have CMake 3.24 or new, it intentionally uses the old behavior for compatibility unless we use `cmake_minimum_required(VERSION 3.24)` (Current llvm uses `3.20.0`).

https://github.com/llvm/llvm-project/pull/79387