[lld] r268056 - ELF: Add -O0 (produce output as fast as possible) mode.
Rui Ueyama via llvm-commits
llvm-commits at lists.llvm.org
Fri Apr 29 16:39:21 PDT 2016
On Linux and on SSD.
On Fri, Apr 29, 2016 at 4:38 PM, David Blaikie <dblaikie at gmail.com> wrote:
> 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/2a6b0075/attachment.html>
More information about the llvm-commits
mailing list