<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">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:0 0 0 .8ex;border-left:1px #ccc 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><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><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc 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 class="HOEnZb"><div class="h5"><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:0 0 0 .8ex;border-left:1px #ccc 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:0 0 0 .8ex;border-left:1px #ccc 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:0 0 0 .8ex;border-left:1px #ccc 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><br></div></div>