<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, May 23, 2018 at 3:25 AM, Peter Smith <span dir="ltr"><<a href="mailto:peter.smith@linaro.org" target="_blank">peter.smith@linaro.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
I think that the approach of using a section to record address<br>
significance is a good one. I'm guessing it will have its own section<br>
type and format? If it does would it make sense to try and submit this<br>
to the GABI <a href="https://groups.google.com/forum/#!forum/generic-abi" rel="noreferrer" target="_blank">https://groups.google.com/foru<wbr>m/#!forum/generic-abi</a> as it<br>
could be potentially useful for other linkers, for example gold?<br></blockquote><div><br></div><div>Yes, there is a new section type (SHT_LLVM_ADDRSIG) and format (a sequence of ULEB128-encoded symbol table indexes that are address-significant).</div><div><br></div><div>I think it makes sense for this to eventually be part of the generic ABI, and I will send a proposal to generic-abi. As I mentioned in my reply to James Knight, I don't think we should block on getting a section number assignment, but we can at least incorporate any design feedback from that proposal.</div><div><br></div><div>Peter</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Happy to help out with reviews.<br>
<br>
Peter<br>
<br>
<br>
On 22 May 2018 at 23:06, Peter Collingbourne via llvm-dev<br>
<div><div class="m_8197017128990209864h5"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> Hi all,<br>
><br>
> Context: ld.gold has an --icf=safe flag which is intended to apply ICF only<br>
> to sections which can be safely merged according to the guarantees provided<br>
> by the language. It works using a set of heuristics (symbol name matching<br>
> and relocation scanning). That's not only imprecise but it only works with<br>
> certain languages and is slow due to the need to demangle symbols and scan<br>
> relocations. It's also redundant with the (local_)unnamed_addr analysis<br>
> already performed by LLVM.<br>
><br>
> I implemented an alternative to this approach in clang and lld. It works by<br>
> adding a section to each object file containing the indexes of the symbols<br>
> which are address-significant (i.e. not (local_)unnamed_addr in IR).<br>
><br>
> I used this implementation to link clang with release+asserts with each of<br>
> --icf={none,safe,all}. The binary sizes were:<br>
><br>
> none: 109407184<br>
> safe: 108534736 (-0.8%)<br>
> all: 107281360 (-2%)<br>
><br>
> I measured the object file overhead of these sections in my clang build at<br>
> 0.08%. That's almost nothing, and I think it's small enough that we can turn<br>
> it on by default.<br>
><br>
> I've uploaded a patch series for this feature here:<br>
> <a href="https://github.com/pcc/llvm-project/tree/llvm-addrsig" rel="noreferrer" target="_blank">https://github.com/pcc/llvm-pr<wbr>oject/tree/llvm-addrsig</a><br>
> I intend to start sending it for review soon.<br>
><br>
> Thanks,<br>
> --<br>
> --<br>
> Peter<br>
><br>
</div></div>> ______________________________<wbr>_________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="m_8197017128990209864gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">-- <div>Peter</div></div></div>
</div></div>