[patch][rfc] Implicit sections

[Rafael Espíndola]

> 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