On Sun, 2 Apr 2023 06:59:02 GMT, Julian Waters wrote:
>> 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
>> fla
On Sun, 2 Apr 2023 06:59:02 GMT, Julian Waters wrote:
>> 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
>> fla
On Thu, 30 Mar 2023 23:38:12 GMT, Julian Waters wrote:
>> 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
>> fl
> 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
On Thu, 30 Mar 2023 23:38:12 GMT, Julian Waters wrote:
>> 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
>> fl
On Thu, 30 Mar 2023 23:38:12 GMT, Julian Waters wrote:
>> 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
>> fl
On Thu, 30 Mar 2023 23:38:12 GMT, Julian Waters wrote:
>> 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
>> fl
On Thu, 30 Mar 2023 23:26:17 GMT, Julian Waters wrote:
>> It may make sense to have the `-O*` argument to the linker match what we do
>> for compilation. I'm not sure how related they are.
>
> Good catch, thanks. Will also add this flag to the opt-size option so it can
> override what link-time
> 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
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
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)
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
> 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
On Fri, 24 Mar 2023 17:12:26 GMT, Julian Waters wrote:
> 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
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 additiona
15 matches
Mail list logo
