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