Re: RFR: 8304893: Link Time Optimization with gcc can be faster [v2]

2023-03-30 Thread Julian Waters
On Wed, 29 Mar 2023 13:32:47 GMT, Erik Joelsson wrote: >> make/hotspot/lib/JvmFeatures.gmk line 173: >> >>> 171: ifeq ($(call isCompiler, gcc), true) >>> 172: JVM_CFLAGS_FEATURES += -flto=$(JOBS) -fuse-linker-plugin >>> -fno-strict-aliasing -fno-fat-lto-objects >>> 173: JVM_LDFLAGS_FE

Re: RFR: 8304893: Link Time Optimization with gcc can be faster [v2]

2023-03-29 Thread Erik Joelsson
On Mon, 27 Mar 2023 05:47:28 GMT, David Holmes wrote: >> Julian Waters has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Comment not required > > make/hotspot/lib/JvmFeatures.gmk line 173: > >> 171: ifeq ($(call isCompiler, gcc), true)

Re: RFR: 8304893: Link Time Optimization with gcc can be faster [v2]

2023-03-28 Thread Julian Waters
On Mon, 27 Mar 2023 05:25:15 GMT, David Holmes wrote: >> Julian Waters has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Comment not required > > make/autoconf/flags-ldflags.m4 line 73: > >> 71: fi >> 72: >> 73: # Moved optimizat

Re: RFR: 8304893: Link Time Optimization with gcc can be faster [v2]

2023-03-28 Thread Julian Waters
> A previous argument against link time optimization support that we have for > gcc is that it was extremely slow. After some checks it turns out we are > passing rather inefficient flags to gcc in optimized builds. Changing these > flags to run the linker optimizations in parallel and passing a