<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, May 23, 2018 at 3:07 PM, Peter Collingbourne <span dir="ltr"><<a href="mailto:peter@pcc.me.uk" target="_blank">peter@pcc.me.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="m_-4565564207922373429gmail-">On Wed, May 23, 2018 at 12:16 PM, Peter Collingbourne <span dir="ltr"><<a href="mailto:peter@pcc.me.uk" target="_blank">peter@pcc.me.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="m_-4565564207922373429gmail-m_-6004254885172308933gmail-">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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></span><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></div></div></blockquote><div><br></div></span><div>I've sent the proposal: <a href="https://groups.google.com/forum/#!topic/generic-abi/MPr8TVtnVn4" target="_blank">https://groups.google.com/foru<wbr>m/#!topic/generic-abi/MPr8TVtn<wbr>Vn4</a></div></div></div></div></blockquote><div><br></div><div>Based on feedback from the generic-abi thread I looked at the object file size and link time impact of a few other representations for the address-significance table. My results are here: <a href="https://groups.google.com/d/msg/generic-abi/MPr8TVtnVn4/30Z0_KHMAQAJ" target="_blank">https://groups.google.<wbr>com/d/msg/generic-abi/<wbr>MPr8TVtnVn4/30Z0_KHMAQAJ</a></div><div><br></div><div>One of the proposals (a compressed array of symbol attributes) is slightly more expensive than what I originally proposed (+0.03% object file size, +1% link time) but it would allow for future expansion and therefore seems more appropriate for the gABI. That's not really a concern for us though since the initial implementation will use a platform-specific section number, and we can always switch to the gABI representation at the same time as we adopt the gABI section numbers. There's also the possibility that we will end up doing something completely different in the gABI.</div><div><br></div><div>Does anyone have a strong opinion that we should do something more aligned with the gABI? If not, I'll start upstreaming my original proposal.</div><div><br></div><div>Peter</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Peter</div><div><div class="m_-4565564207922373429gmail-h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Peter</div><div><div class="m_-4565564207922373429gmail-m_-6004254885172308933gmail-h5"><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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_-4565564207922373429gmail-m_-6004254885172308933gmail-m_-6698097828168061625m_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></div></div><span class="m_-4565564207922373429gmail-m_-6004254885172308933gmail-HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div class="m_-4565564207922373429gmail-m_-6004254885172308933gmail-m_-6698097828168061625m_8197017128990209864gmail_signature"><div dir="ltr">-- <div>Peter</div></div></div>
</font></span></div></div>
</blockquote></div></div></div><span class="m_-4565564207922373429gmail-HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div class="m_-4565564207922373429gmail-m_-6004254885172308933gmail_signature"><div dir="ltr">-- <div>Peter</div></div></div>
</font></span></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="m_-4565564207922373429gmail_signature"><div dir="ltr">-- <div>Peter</div></div></div>
</div></div>