<div dir="ltr">The hash approach was suggested by others as well, but I think for now we can use the sh_link field until the tools are updated -- that was the recommended approach on the generic-abi thread as well. Keep in mind that updating the gABI is really orthogonal to the compatibility issue: even with an updated gABI we'd still have the practical problem of needing to deal with old tools somehow.<div><br></div><div>Agreed that we'd be fine pessimising ld -r -- the main thing that I'm concerned about is avoiding miscompiles caused by shuffling symbols.</div><div><br></div><div><div>Peter</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 31, 2018 at 1:52 PM, bd1976 llvm <span dir="ltr"><<a href="mailto:bd1976llvm@gmail.com" target="_blank">bd1976llvm@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi Peter, This is a great proposal, thanks!. </div><div><br></div><div>If you were worried about making the abi change have you</div><div>thought about just going for an array of symbol names</div><div>or hashes of symbol names where any matching symbol is</div><div>considered address significant? This would sidestep the</div><div>problem of keeping the symbol table indices in sync.</div><div><br></div><div>It would be pessimistic for local symbols if the input </div><div>SHT_ADDRSIG sections were combined by e.g. "ld -r" but</div><div>in my experience this should not have too much of an</div><div>impact on --icf. </div><div><br></div><div>Might be worth considering in the short term whilst you</div><div>work on getting gabi acceptance.</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Tue, May 22, 2018 at 11:06 PM, Peter Collingbourne via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div>Hi all,</div><div><br></div>Context: ld.gold has an --icf=safe flag which is intended to apply ICF only to sections which can be safely merged according to the guarantees provided by the language. It works using a set of heuristics (symbol name matching and relocation scanning). That's not only imprecise but it only works with certain languages and is slow due to the need to demangle symbols and scan relocations. It's also redundant with the (local_)unnamed_addr analysis already performed by LLVM.<div><br></div><div>I implemented an alternative to this approach in clang and lld. It works by adding a section to each object file containing the indexes of the symbols which are address-significant (i.e. not (local_)unnamed_addr in IR).<br><div><br></div><div>I used this implementation to link clang with release+asserts with each of --icf={none,safe,all}. The binary sizes were:</div><div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">none: 109407184</div></div><div><div>safe: 108534736 (-0.8%)<br></div></div><div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">all: 107281360 (-2%)<br></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><br></div></div><div>I measured the object file overhead of these sections in my clang build at 0.08%. That's almost nothing, and I think it's small enough that we can turn it on by default.</div><div><br></div><div>I've uploaded a patch series for this feature here: <a href="https://github.com/pcc/llvm-project/tree/llvm-addrsig" target="_blank">https://github.com/pcc/l<wbr>lvm-project/tree/llvm-addrsig</a></div><div>I intend to start sending it for review soon.</div><div><br></div><div>Thanks,<span class="m_-2076009459556336991HOEnZb"><font color="#888888"><br>-- <br><div class="m_-2076009459556336991m_-6706644408177551337gmail_signature"><div dir="ltr">-- <div>Peter</div></div></div>
</font></span></div></div></div>
<br></div></div><span class="">______________________________<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></span></blockquote></div><br></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">-- <div>Peter</div></div></div>
</div>