<div dir="ltr">Looks fine to me. There are some concerns with a linker that does this and things that require mucking about with them, but this patch is just fine as other linkers aren't going to be affected anyhow :)<br><div><br></div><div>-eric</div></div><br><div class="gmail_quote">On Thu Feb 12 2015 at 12:37:57 PM Rafael Espíndola <<a href="mailto:rafael.espindola@gmail.com">rafael.espindola@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Updated patch using TargetOptions is attached.<br>
<br>
On 12 February 2015 at 11:03, Rafael Espíndola<br>
<<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>> wrote:<br>
>> Isnt this same as the Atom model with lld, lld uses symbol size to construct<br>
>> atoms.<br>
><br>
> No, but IMHO it is what it *should* be :-)<br>
> These are still sections. You can have as many symbols in them as you<br>
> like. This lets you implement multiple entries, data close to code,<br>
> etc.<br>
><br>
>> While this improves GC, what about :-<br>
><br>
> It doesn't. What can be GCed with this patch is exactly what can be<br>
> gced with -ffunction-sections/-fdata-<u></u>sections. This is only an<br>
> optimization on the size of the .o files.<br>
><br>
>> a) linker script rules.<br>
>> b) how is COMDAT handled<br>
>> c) How are section relative relocations translated ? I believe it uses a<br>
>> section symbol + offset, how would this be taken care.<br>
><br>
> Not changed at all. That is the nice thing about this strategy. The<br>
> rules are exactly the same as having multiple sections.<br>
><br>
>>> As part of the work of upstreaming the llvm changes, I have been<br>
>>> looking at a way to view and implement this as a general and sound<br>
>>> optimization.<br>
>>><br>
>>> In order to be able to split sections, the linker needs extra<br>
>>> relocations. In fact, it needs the same relocations as would be needed<br>
>>> if -ffunction-sections and -fdata-sections were used.<br>
>><br>
>> Why dont we use -ffunction-sections and -fdata-sections by default.<br>
><br>
> The two arguments I have heard are:<br>
><br>
> * The overhead in size and link time.<br>
> * Different behavior from gcc.<br>
><br>
> With this patch the overhead is down to about 1.06X on the size of the<br>
> .o files. I haven't timed the link time overhead when gc is not done,<br>
> but maybe once this is in we can reconsider<br>
> -ffunction-sections/-fdata-<u></u>sections by default.<br>
><br>
>> What is the alignment of each individual section that has been split ?<br>
><br>
> My understanding is that it will have the same as it would have with a<br>
> plain -ffunction-section/-fdata-<u></u>section or higher (if it just so<br>
> happens to end up more aligned).<br>
><br>
>>> The patch needs a bit more work (proper option instead of cl::opt,<br>
>>> more compact encoding), but it can bootstrap and saves some space in<br>
>>> the .o files. In a build dir after running "ninja && ninja check-all"<br>
>>> the total size of the .o files goes from 237871087 bytes to 231292287.<br>
>><br>
>> I couldnt follow how does this save space ?<br>
><br>
> By avoiding long section names.<br>
><br>
>>> The patch also offers some saving even when<br>
>>> -ffunction-sections/-fdata-<u></u>sections are not used by avoiding long<br>
>>> names in comdats.<br>
>>><br>
>>> The next step would then be to add an "implicit" flag in addition to<br>
>>> the "unique" one. This would mean that when given<br>
>>><br>
>>> .section .text,"ax",@progbits, implicit<br>
>>> .section .text,"ax",@progbits, implicit<br>
>><br>
>> How does partial linking work ?<br>
><br>
> What do you mean by that? The implicit will not even survive to the<br>
> .o. It is  just a tool for creating the correct relocations in MC.<br>
><br>
>>> With this in then the default for PS4 would be changed to<br>
>>> -ffunction-sections, -fdata-sections and implicit sections.<br>
>>><br>
>>> The advantage of implementing it this way is that it makes it clear<br>
>>> that it is really just a .o compactness optimization. No extra logic<br>
>>> is required for deciding if a relocation is needed. The extra handling<br>
>>> of "implicit" would be just in the ELF object writer.<br>
>><br>
>> Curious, is this planned in binutils too ?<br>
><br>
> I am not planning on implementing it right now. It would be an extra<br>
> feature requiring the use of MC.<br>
><br>
> Cheers,<br>
> Rafael<br>
______________________________<u></u>_________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvm-commits</a><br>
</blockquote></div>