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

[George Rimar via llvm-commits]

>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.

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/93011c4b/attachment.html>