On Fri, 15 Nov 2024 10:37:31 GMT, Kim Barrett <kbarr...@openjdk.org> wrote:
>> LTO seems to be less than a factor of 2 longer build times. If it makes a >> measurable difference in performance, that seems like a clear win for >> production builds. Certainly hotspot developers wouldn't want it on, but we >> will know about that, just like using ccache and not using precompiled >> headers >> for incremental development. >> >> Thanks for clarifying the incremental linking thing. >> >> The relevant gcc bug regarding pragmas not carrying through to LTO is >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80922 >> #pragma diagnostic ignored not honoured with -flto >> It's been around for a few years now, with no obvious progress. >> >> I failed to understand the proposal for 8313396. I took another look today, >> and I'm still not getting it. Maybe we should talk about it over there. > > For the record, I'm seeing 3 warnings, 2 of which are for the same code. Both > are -Walloc-size-larger-than= warnings for calls to operator new[]. > > In gtestMain.cpp, in init_jvm, `new JavaVMOption[num_jvm_options]` is being > warned about. The warning is obviously wrong, as the value it is complaining > about uint64_max, while the variable has int type. > > The other is in (non-Windows) CreateArgvFromArgs in gtest-death-test.cc, and > is being too conservative about value bounds, so also wrong. > > So both of these appear to be LTO bugs. > > Of course, it's not possible to suppress these warnings via pragmas, because > of the bug that LTO doesn't honor such. 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22069#discussion_r1844284965
