[lld] r268056 - ELF: Add -O0 (produce output as fast as possible) mode.
David Blaikie via llvm-commits
llvm-commits at lists.llvm.org
Fri Apr 29 16:38:25 PDT 2016
On Windows, I imagine? On an SSD I assume?
Don't imagine there's much reason to believe it'd be substantially
different on Linux.
Thanks for comparing!
On Fri, Apr 29, 2016 at 4:35 PM, Rui Ueyama <ruiu at google.com> wrote:
> Touched a single cc file and and rerun ninja check-clang with and without
> -O0. The two cases were in the same ballpark.
>
> With -O0
>
> Testing Time: 71.21s
> Expected Passes : 9253
> Expected Failures : 16
> Unsupported Tests : 18
>
> real 2m8.528s
> user 30m7.967s
> sys 5m54.938s
>
> Without -O0
>
> Testing Time: 72.62s
> Expected Passes : 9253
> Expected Failures : 16
> Unsupported Tests : 18
>
> real 2m9.602s
> user 29m53.452s
> sys 5m51.387s
>
> On Fri, Apr 29, 2016 at 3:51 PM, David Blaikie <dblaikie at gmail.com> wrote:
>
>> Anyone want to test how fast this is to touch a single cc file, relink,
>> rerun all the clang+llvm tests using this option (preferrably on an SSD)?
>>
>> Be interesting to know if the increased code size slows down the test
>> execution enough to wash out the benefit of the improved link time (as is
>> the case with a shared library build - but of course there the overhead
>> (loading the shared libraries) is greater)
>>
>> On Fri, Apr 29, 2016 at 9:12 AM, Rui Ueyama via llvm-commits <
>> llvm-commits at lists.llvm.org> wrote:
>>
>>> Author: ruiu
>>> Date: Fri Apr 29 11:12:29 2016
>>> New Revision: 268056
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=268056&view=rev
>>> Log:
>>> ELF: Add -O0 (produce output as fast as possible) mode.
>>>
>>> This patch redefines the default optimization level as 1 and adds
>>> new level 0. In the command line, it is -O0. The flag disables
>>> costly but optional features so that the linker produces semantically
>>> correct but larger output quickly. Currently it only disables
>>> section merging.
>>>
>>> This flag is not intended to be used for final production linking.
>>> It is intended to be used in compile-link-test cycle.
>>>
>>> Time to link clang with debug info is about 2x faster with the flag.
>>>
>>> Head:
>>> 13.24 seconds
>>> Output size: 1227189664 bytes
>>>
>>> With this patch:
>>> 7.41 seconds
>>> Output size: 2490281784 bytes
>>>
>>> Differential Revision: http://reviews.llvm.org/D19705
>>>
>>> Modified:
>>> lld/trunk/ELF/Driver.cpp
>>> lld/trunk/ELF/InputFiles.cpp
>>> lld/trunk/test/ELF/merge-string.s
>>>
>>> Modified: lld/trunk/ELF/Driver.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/lld/trunk/ELF/Driver.cpp?rev=268056&r1=268055&r2=268056&view=diff
>>>
>>> ==============================================================================
>>> --- lld/trunk/ELF/Driver.cpp (original)
>>> +++ lld/trunk/ELF/Driver.cpp Fri Apr 29 11:12:29 2016
>>> @@ -356,7 +356,7 @@ void LinkerDriver::readConfigs(opt::Inpu
>>> Config->SoName = getString(Args, OPT_soname);
>>> Config->Sysroot = getString(Args, OPT_sysroot);
>>>
>>> - Config->Optimize = getInteger(Args, OPT_O, 0);
>>> + Config->Optimize = getInteger(Args, OPT_O, 1);
>>> Config->LtoO = getInteger(Args, OPT_lto_O, 2);
>>> if (Config->LtoO > 3)
>>> error("invalid optimization level for LTO: " + getString(Args,
>>> OPT_lto_O));
>>>
>>> Modified: lld/trunk/ELF/InputFiles.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/lld/trunk/ELF/InputFiles.cpp?rev=268056&r1=268055&r2=268056&view=diff
>>>
>>> ==============================================================================
>>> --- lld/trunk/ELF/InputFiles.cpp (original)
>>> +++ lld/trunk/ELF/InputFiles.cpp Fri Apr 29 11:12:29 2016
>>> @@ -143,6 +143,12 @@ elf::ObjectFile<ELFT>::getShtGroupEntrie
>>>
>>> template <class ELFT> static bool shouldMerge(const typename ELFT::Shdr
>>> &Sec) {
>>> typedef typename ELFT::uint uintX_t;
>>> +
>>> + // We don't merge sections if -O0 (default is -O1). This makes
>>> sometimes
>>> + // the linker significantly faster, although the output will be
>>> bigger.
>>> + if (Config->Optimize == 0)
>>> + return false;
>>> +
>>> uintX_t Flags = Sec.sh_flags;
>>> if (!(Flags & SHF_MERGE))
>>> return false;
>>>
>>> Modified: lld/trunk/test/ELF/merge-string.s
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/lld/trunk/test/ELF/merge-string.s?rev=268056&r1=268055&r2=268056&view=diff
>>>
>>> ==============================================================================
>>> --- lld/trunk/test/ELF/merge-string.s (original)
>>> +++ lld/trunk/test/ELF/merge-string.s Fri Apr 29 11:12:29 2016
>>> @@ -4,6 +4,8 @@
>>> // RUN: llvm-readobj -s -section-data -t %t.so | FileCheck %s
>>> // RUN: ld.lld -O1 %t.o -o %t.so -shared
>>> // RUN: llvm-readobj -s -section-data -t %t.so | FileCheck
>>> --check-prefix=NOTAIL %s
>>> +// RUN: ld.lld -O0 %t.o -o %t.so -shared
>>> +// RUN: llvm-readobj -s -section-data -t %t.so | FileCheck
>>> --check-prefix=NOMERGE %s
>>>
>>> .section .rodata.str1.1,"aMS", at progbits,1
>>> .asciz "abc"
>>> @@ -55,6 +57,24 @@ zed:
>>> // NOTAIL-NEXT: 0000: 61626300 626300 |abc.bc.|
>>> // NOTAIL-NEXT: )
>>>
>>> +// NOMERGE: Name: .rodata
>>> +// NOMERGE-NEXT: Type: SHT_PROGBITS
>>> +// NOMERGE-NEXT: Flags [
>>> +// NOMERGE-NEXT: SHF_ALLOC
>>> +// NOMERGE-NEXT: SHF_MERGE
>>> +// NOMERGE-NEXT: SHF_STRINGS
>>> +// NOMERGE-NEXT: ]
>>> +// NOMERGE-NEXT: Address: 0x1C8
>>> +// NOMERGE-NEXT: Offset: 0x1C8
>>> +// NOMERGE-NEXT: Size: 16
>>> +// NOMERGE-NEXT: Link: 0
>>> +// NOMERGE-NEXT: Info: 0
>>> +// NOMERGE-NEXT: AddressAlignment: 2
>>> +// NOMERGE-NEXT: EntrySize: 0
>>> +// NOMERGE-NEXT: SectionData (
>>> +// NOMERGE-NEXT: 0000: 61626300 61626300 62630000 14000000
>>> |abc.abc.bc......|
>>> +// NOMERGE-NEXT: )
>>> +
>>> // CHECK: Name: .rodata
>>> // CHECK-NEXT: Type: SHT_PROGBITS
>>> // CHECK-NEXT: Flags [
>>>
>>>
>>> _______________________________________________
>>> llvm-commits mailing list
>>> llvm-commits at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160429/2fb2d204/attachment-0001.html>
More information about the llvm-commits
mailing list