RFR: 8343698: Linux x86_64 lto build gives a lot of warnings and fails lto-wrapper: fatal error: make returned 2 exit status [v2]
Matthias Baesken
mbaesken at openjdk.org
Mon Nov 18 08:53:43 UTC 2024
On Fri, 15 Nov 2024 18:36:51 GMT, Julian Waters <jwaters at openjdk.org> wrote:
>> Catching up with the discussion...
>>
>> LTO has been working before, and was indeed enabled for the old embedded platform. Since then, it has not been regularly tested and has certainly bit-rottet.
>>
>> I think it is a good thing to try to keep it alive. There is potential for big performance improvements, even if that will only be utilized for special builds. The additional build time is the main culprit here. But it is possible that, as Kim says, the *entire* build is perhaps "just" slowed down by a factor of 2x, and that might be acceptable, even if the Hotspot build is slowed down several magnitudes.
>>
>> Also, there are many promising efforts going on right now, that is trying to get some or all of the LTO benefits in different ways. In particular, iirc, the LLVM linker lld has some kind of "partial LTO" which, iiuc, tries to pick the most important aspeect of LTOs but implemented in a way that has minimal build performance impact.
>>
>> It is not entirely clear what correspondence there is between keeping the traditional gcc LTO alive, and being able to use this new clang partial LTO, but as a reasonable first guess it will be helpful to keep it working.
>
> The old LTO used to set -O3 directly on both LDFLAGS and CFLAGS, bypassing OPTIMIZATION variable entirely. Just wanted to put this out there, since the topic of traditional gcc LTO came up. I changed that to set OPTIMIZATION to HIGHEST_JVM some time ago, and I'm not sure whether my change played any part in breaking LTO
>
> LTO is currently only supported for VC and gcc. I can look into how to implement it for clang, though not now. First I'm committed to fixing all the issues with LTO, and making sure Kim's worry of poisoning virtually disappearing when LTO is enabled doesn't become a reality
Agree, we should support LTO for gcc AND clang on Linux/macOS.
Regarding the longer link/build times , I can add some info how much longer it takes in our environment (SUSE Linux/gcc).
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/22069#discussion_r1846107207
More information about the build-dev
mailing list