<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 23, 2016 at 4:30 PM, Sean Silva <span dir="ltr"><<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Tue, Feb 23, 2016 at 3:25 PM, Rui Ueyama <span dir="ltr"><<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">By the way, for ICF, I think we eventually want to have the compiler emit a (cryptographically-safe) hash value for each section to eliminate byte-by-byte comparison.</div></blockquote><div><br></div></span><div>What fraction of time in ICF is spent doing section content comparisons? How many times is each section's content actually looked at? Currently we have to scan the entire section every time we get to the comparison end of equalsConstant. If we cache a hash value computed during that scan (even if it is not a super great hash) we could probably avoid a number of the scans.</div></div></div></div></blockquote><div><br></div><div>We have data for COFF. <a href="http://llvm.org/viewvc/llvm-project?view=revision&revision=247961">http://llvm.org/viewvc/llvm-project?view=revision&revision=247961</a></div><div><br></div><div>"LLD took 1198 ms to link itself to produce a 27.11 MB executable. Of which, ICF accounted for 536 ms. This patch cuts it by 90 ms, which is 17% speedup of ICF and 7.5% speedup overall. All numbers are median of ten runs."</div><div><br></div><div>Note that checksums in COFF is not cryptographically strong but just CRC32, so we do compare section contents at last. This could have been eliminated if they chose to use MD5 or SHA1. That means the above number is more like a lower-bound.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><font color="#888888"><div>-- Sean Silva</div></font></span><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>That would not only greatly reduce time we spent on ICF but also on build-id computation. "--build-id" option is casually added to the linker command line, but that is actually pretty expensive operation. For example, GNU gold spends about 10% link time just for computing a hash value.</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 23, 2016 at 3:12 PM, Sean Silva via llvm-commits <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Tue, Feb 23, 2016 at 2:32 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>> I think the "take the address" part is the crucial hint. Can't you tell<br>
> from the combination of visibility and relocations what functions are<br>
> safe to merge? The only tricky part I can imagine is identifying<br>
> vtables, as they do not classify as pointer leak.<br>
<br>
</span>Somewhat. Gold has that on its list of heuristics, but it is pretty<br>
nasty. In particular, using files compiled with -fPIC to produce<br>
regular executables breaks the heuristic.<br>
<br>
Lets focus on the non-safe version for now. When time comes I think<br>
the correct thing to do is to implement the nop padding as it is<br>
always safe and then propose adding a flag to ELF to say that a<br>
particular section/symbol doesn't need an unique address.<br></blockquote><div><br></div></span><div>Yeah. The compiler already knows the this information. No need for the linker to bend over backward to try to recover it.</div><div><br></div><div>-- Sean Silva</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Cheers,<br>
Rafael<br>
<div><div>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></span></div><br></div></div>
<br>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div></div>