[PATCH] D41993: [ELF] - Change shift2 constant of GNU_HASH from 6->11.

[Rui Ueyama via llvm-commits]

On Fri, Jan 19, 2018 at 12:30 AM, George Rimar <grimar at accesssoftek.com>
wrote:

> >I don't believe that spending time on "tuning" shift2 value is a good
> idea because I doubt that that is theoretically meaningful.
>
> > If my understanding is correct, changing that value doesn't have any
> significant effects.
>
> It have effect. Setting to values >= 11 gives boost for llvm-check. Even
> given that results are varie a bit,
> Time(Shift2=6) is always noticable worse than Time(Shift2=11).
> It is not a calculation error, difference is stable.
>

Your benchmark scores depend on symbol names exported from DSO files. 11
might achieve better performance than 6 in your testcase, but that doesn't
mean 11 is always better than the others in other test cases. IIUC,
theoretically, as I said, no number should be better than the others as
long as the hash function returns evenly distributed hash values. Please
explain your theory behind why 11 is better than 6 if you want to proceed
with this patch.

I am not much in favor of tuning it too much, because anyways in linker we
> do not have information about all symbols that loader
> will try to lookup. So I believe it is just impossible to find ideal
> .gnu_hash. But I would hardcode any value in [11,20] instead of 6 probably,
> it is a free boost.
>
> >The bloom filter for the .gnu.hash table is a two-bit bloom filter. To
> choose two bit locations, we compute one hash value H and create
> >two hash values H1 and H2 in the following manner :Assume a 64-bit
> machine. Bits H[0,5] are always used for computing the
> >first hash H1. Bits H[Shift2, Shift2 + 5] are used for computing the
> second hash H2.​
> >As long as the hash function produces evenly distributed hash values,
> choosing bits [6, 11] isn't different from choosing other bits, say [15,
> 20].
> >No Shift2 greater than 5 should be better than any other Shift2 values in
> theory.
> >
> >Am I missing something?
>
> I think there is a mistake here. See, we have following code:
> Val |= uint64_t(1) << (Sym.Hash % C);
> Val |= uint64_t(1) << ((Sym.Hash >> getShift2()) % C);
> C == 64 for 64 bits, ot 2^6. It is simplified to:
> Val |= uint64_t(1) << (Sym.Hash >> 6);
> Val |= uint64_t(1) << (Sym.Hash >> (Shift2 + 6));
> Or I believe bits H[6, 63] are used to find Bit 1 and H[6 + Shift2, 63]
> for Bit 2.​
>
> George.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180119/b16ac01e/attachment.html>