[llvm] r227431 - Don't create multiple mergeable sections with -fdata-sections.
Rafael Espíndola
rafael.espindola at gmail.com
Fri Jan 30 22:20:58 PST 2015
Can you confirm if all the increase is in the .rodata section? What are the
steps you used? I will be back at my desktop on Monday and can try fixing
it.
On Jan 30, 2015 10:42 PM, "Nico Weber" <thakis at chromium.org> wrote:
> I built clang at r227430 and r227431 and used each to build chrome on
> linux in static library build (so most code goes into the final executable,
> instead of having many .so files).
>
> Without the patch, rebuilding after touching a small cc file takes 14.0s
> (min of 3 builds following 1 build to warm up caches). With the patch, it's
> 13.8s. Binary size goes from 144,060,288 to 144,342,192, a 282 kB increase.
> I didn't look at combined .o size, since that doesn't seem like an
> interesting metric. So this looks more like a regression from over here.
> (This is with GNU gold (GNU Binutils 2.24) 1.11).
>
> Nico
>
> On Thu, Jan 29, 2015 at 8:57 AM, David Blaikie <dblaikie at gmail.com> wrote:
>
>>
>> On Jan 29, 2015 4:46 AM, "Rafael Espindola" <rafael.espindola at gmail.com>
>> wrote:
>> >
>> > Author: rafael
>> > Date: Thu Jan 29 06:43:28 2015
>> > New Revision: 227431
>> >
>> > URL: http://llvm.org/viewvc/llvm-project?rev=227431&view=rev
>> > Log:
>> > Don't create multiple mergeable sections with -fdata-sections.
>> >
>> > ELF has support for sections that can be split into fixed size or
>> > null terminated entities.
>> >
>> > Since these sections can be split by the linker, it is not necessary
>> > to split them in codegen.
>> >
>> > This reduces the combined .o size in a llvm+clang build from
>> > 202,394,570 to 173,819,098 bytes.
>>
>> Nice! - though the linked binary size is essentially the same (bar the
>> rodata you mentioned below - hmm, chrome is fussy about executable
>> size...)?
>>
>> >
>> > The time for linking clang with gold (on a VM, on a laptop) goes
>> > from 2.250089985 to 1.383001792 seconds.
>>
>> That sounds pretty awesome! Though I thought my gold links even on my
>> non-virtual beefy desktop were longer than that. Perhaps not.
>>
>> >
>> > The flip side is the size of rodata in clang goes from 10,926,785
>> > to 10,929,345 bytes.
>> >
>> > The increase seems to be because of
>> http://sourceware.org/bugzilla/show_bug.cgi?id=17902.
>> >
>> > Modified:
>> > llvm/trunk/lib/CodeGen/TargetLoweringObjectFileImpl.cpp
>> > llvm/trunk/test/CodeGen/X86/global-sections.ll
>> >
>> > Modified: llvm/trunk/lib/CodeGen/TargetLoweringObjectFileImpl.cpp
>> > URL:
>> http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/TargetLoweringObjectFileImpl.cpp?rev=227431&r1=227430&r2=227431&view=diff
>> >
>> ==============================================================================
>> > --- llvm/trunk/lib/CodeGen/TargetLoweringObjectFileImpl.cpp (original)
>> > +++ llvm/trunk/lib/CodeGen/TargetLoweringObjectFileImpl.cpp Thu Jan 29
>> 06:43:28 2015
>> > @@ -246,24 +246,25 @@ static StringRef getSectionPrefixForGlob
>> > const MCSection *TargetLoweringObjectFileELF::
>> > SelectSectionForGlobal(const GlobalValue *GV, SectionKind Kind,
>> > Mangler &Mang, const TargetMachine &TM) const {
>> > + unsigned Flags = getELFSectionFlags(Kind);
>> > +
>> > // If we have -ffunction-section or -fdata-section then we should
>> emit the
>> > // global value to a uniqued section specifically for it.
>> > - bool EmitUniquedSection;
>> > - if (Kind.isText())
>> > - EmitUniquedSection = TM.getFunctionSections();
>> > - else
>> > - EmitUniquedSection = TM.getDataSections();
>> > + bool EmitUniquedSection = false;
>> > + if (!(Flags & ELF::SHF_MERGE) && !Kind.isCommon()) {
>> > + if (Kind.isText())
>> > + EmitUniquedSection = TM.getFunctionSections();
>> > + else
>> > + EmitUniquedSection = TM.getDataSections();
>> > + }
>> >
>> > - // If this global is linkonce/weak and the target handles this by
>> emitting it
>> > - // into a 'uniqued' section name, create and return the section now.
>> > - if ((EmitUniquedSection && !Kind.isCommon()) || GV->hasComdat()) {
>> > + if (EmitUniquedSection || GV->hasComdat()) {
>> > StringRef Prefix = getSectionPrefixForGlobal(Kind);
>> >
>> > SmallString<128> Name(Prefix);
>> > TM.getNameWithPrefix(Name, GV, Mang, true);
>> >
>> > StringRef Group = "";
>> > - unsigned Flags = getELFSectionFlags(Kind);
>> > if (const Comdat *C = getELFComdat(GV)) {
>> > Flags |= ELF::SHF_GROUP;
>> > Group = C->getName();
>> >
>> > Modified: llvm/trunk/test/CodeGen/X86/global-sections.ll
>> > URL:
>> http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/X86/global-sections.ll?rev=227431&r1=227430&r2=227431&view=diff
>> >
>> ==============================================================================
>> > --- llvm/trunk/test/CodeGen/X86/global-sections.ll (original)
>> > +++ llvm/trunk/test/CodeGen/X86/global-sections.ll Thu Jan 29 06:43:28
>> 2015
>> > @@ -121,7 +121,7 @@ define void @F1() {
>> > ; LINUX: G7:
>> > ; LINUX: .asciz "abcdefghi"
>> >
>> > -; LINUX-SECTIONS: .section .rodata.G7,"aMS", at progbits,1
>> > +; LINUX-SECTIONS: .section .rodata.str1.1,"aMS", at progbits,1
>> > ; LINUX-SECTIONS: .globl G7
>> >
>> > ; WIN32-SECTIONS: .section .rdata,"rd",one_only,_G7
>> > @@ -182,7 +182,7 @@ define void @F1() {
>> > @G14 = private unnamed_addr constant [4 x i8] c"foo\00", align 1
>> >
>> > ; LINUX-SECTIONS: .type .LG14, at object # @G14
>> > -; LINUX-SECTIONS: .section
>> .rodata..LG14,"aMS", at progbits,1
>> > +; LINUX-SECTIONS: .section
>> .rodata.str1.1,"aMS", at progbits,1
>> > ; LINUX-SECTIONS: .LG14:
>> > ; LINUX-SECTIONS: .asciz "foo"
>> > ; LINUX-SECTIONS: .size .LG14, 4
>> > @@ -206,7 +206,7 @@ define void @F1() {
>> > ; DARWIN64: .section __TEXT,__const
>> > ; DARWIN64: _G15:
>> >
>> > -; LINUX-SECTIONS: .section .rodata.G15,"aM", at progbits,8
>> > +; LINUX-SECTIONS: .section .rodata.cst8,"aM", at progbits,8
>> > ; LINUX-SECTIONS: G15:
>> >
>> > ; WIN32-SECTIONS: .section .rdata,"rd",one_only,_G15
>> >
>> >
>> > _______________________________________________
>> > llvm-commits mailing list
>> > llvm-commits at cs.uiuc.edu
>> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150131/c16c9dc1/attachment.html>
More information about the llvm-commits
mailing list