<div dir="ltr">I don't have time at the moment too, so filed as <a href="https://bugs.llvm.org/show_bug.cgi?id=35536">https://bugs.llvm.org/show_bug.cgi?id=35536</a> to not forget this.</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 5, 2017 at 8:38 AM, Rafael Avila de Espindola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> writes:<br>
<br>
> 960 and 1031 aren't that different, and not using the prime number<br>
> shouldn't make change as long as the lengths of hash chains are not too<br>
> biased (which I believe true).<br>
><br>
> I took a quick look at `do_lookup_x` function in elf/dl-lookup.c in glibc,<br>
> and looks like the penalty of hash collision is pretty low there (we just<br>
> need to skip a uint32_t value for each collision.)<br>
><br>
> So the difference is interesting.<br>
<br>
</span>I honestly don't have the time to test it further, but it is pretty<br>
simple to experiment if you are interested:<br>
<br>
* Build a regular release of llvm+clang+lld in directory build.<br>
* Mount a tmpfs in build2<br>
* Use build to configure (cmake) a llvm in build2 with BUILD_SHARED_LIBS<br>
* Run ninja check-llvm<br>
* Run perf stat/record llvm-lit ... (copy and past the command from<br>
  ninja -v check-llvm)<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div>