On Fri, 15 Nov 2024 18:36:51 GMT, Julian Waters <jwat...@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
