[patch][rfc] Implicit sections

Rafael EspĂ­ndola rafael.espindola at gmail.com
Thu Feb 12 12:10:14 PST 2015


Updated patch using TargetOptions is attached.

On 12 February 2015 at 11:03, Rafael EspĂ­ndola
<rafael.espindola at gmail.com> wrote:
>> Isnt this same as the Atom model with lld, lld uses symbol size to construct
>> atoms.
>
> No, but IMHO it is what it *should* be :-)
> These are still sections. You can have as many symbols in them as you
> like. This lets you implement multiple entries, data close to code,
> etc.
>
>> While this improves GC, what about :-
>
> It doesn't. What can be GCed with this patch is exactly what can be
> gced with -ffunction-sections/-fdata-sections. This is only an
> optimization on the size of the .o files.
>
>> a) linker script rules.
>> b) how is COMDAT handled
>> c) How are section relative relocations translated ? I believe it uses a
>> section symbol + offset, how would this be taken care.
>
> Not changed at all. That is the nice thing about this strategy. The
> rules are exactly the same as having multiple sections.
>
>>> As part of the work of upstreaming the llvm changes, I have been
>>> looking at a way to view and implement this as a general and sound
>>> optimization.
>>>
>>> In order to be able to split sections, the linker needs extra
>>> relocations. In fact, it needs the same relocations as would be needed
>>> if -ffunction-sections and -fdata-sections were used.
>>
>> Why dont we use -ffunction-sections and -fdata-sections by default.
>
> The two arguments I have heard are:
>
> * The overhead in size and link time.
> * Different behavior from gcc.
>
> With this patch the overhead is down to about 1.06X on the size of the
> .o files. I haven't timed the link time overhead when gc is not done,
> but maybe once this is in we can reconsider
> -ffunction-sections/-fdata-sections by default.
>
>> What is the alignment of each individual section that has been split ?
>
> My understanding is that it will have the same as it would have with a
> plain -ffunction-section/-fdata-section or higher (if it just so
> happens to end up more aligned).
>
>>> The patch needs a bit more work (proper option instead of cl::opt,
>>> more compact encoding), but it can bootstrap and saves some space in
>>> the .o files. In a build dir after running "ninja && ninja check-all"
>>> the total size of the .o files goes from 237871087 bytes to 231292287.
>>
>> I couldnt follow how does this save space ?
>
> By avoiding long section names.
>
>>> The patch also offers some saving even when
>>> -ffunction-sections/-fdata-sections are not used by avoiding long
>>> names in comdats.
>>>
>>> The next step would then be to add an "implicit" flag in addition to
>>> the "unique" one. This would mean that when given
>>>
>>> .section .text,"ax", at progbits, implicit
>>> .section .text,"ax", at progbits, implicit
>>
>> How does partial linking work ?
>
> What do you mean by that? The implicit will not even survive to the
> .o. It is  just a tool for creating the correct relocations in MC.
>
>>> With this in then the default for PS4 would be changed to
>>> -ffunction-sections, -fdata-sections and implicit sections.
>>>
>>> The advantage of implementing it this way is that it makes it clear
>>> that it is really just a .o compactness optimization. No extra logic
>>> is required for deciding if a relocation is needed. The extra handling
>>> of "implicit" would be just in the ELF object writer.
>>
>> Curious, is this planned in binutils too ?
>
> I am not planning on implementing it right now. It would be an extra
> feature requiring the use of MC.
>
> Cheers,
> Rafael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t.patch
Type: text/x-patch
Size: 13239 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150212/7a5ba17f/attachment.bin>


More information about the llvm-commits mailing list