RFR: 8343698: Linux x86_64 lto build gives a lot of warnings and fails lto-wrapper: fatal error: make returned 2 exit status [v2]

[Julian Waters]

On Fri, 15 Nov 2024 18:18:37 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> 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.

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

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22069#discussion_r1844305874