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

[George Rimar via llvm-commits]

>If you have a patch that can try every non zero value of shift2, would
>you mind trying selecting the value that produces the most 0s and the
>most 1s?
>
>Thanks,
>Rafael

Patches are in attachment.
Results for llvm-check for me are:
LLD head rev (r323036): 410.27s, 410.58s.
most_1.patch: 400.71s, 400.29s.
most_0.patch: 418.02s, 417.11s.

Results seems shows that the more filter is filled is better for this particular testcase.

So to summarize my theory in short:
I guess that happens because symbol names that loader tries to lookup has the similar
nature to those we use for building .gnu_hash. And so during lookup it looks has more chance
to avoid false positive, since our filter size is already large (and so has enough zeroes anyways),
and tweaking Shift2 to produce most 1s probably better than have less bits set in a filter entry word.
(when bits are more localized, we looks have more chance to select the same bits during lookup and have
false positive).

I guess if we link some application, it is fine to optimize .gnu_hash table for some symbols and assume
that nature of symbol names will be similar with names that loader will try to lookup. Probably.

I do not know if hash function mentioned in this thread returns evenly distributed hash values. 
Test that used random names showed that Shift2 choice affects on how much bits will be set in bloom filter. 
I would expect no difference for different Shift2 if values would be evenly distributed.

"most_0", "most_1" and "random names" tests looks shows that filter density depends on Shift2 value.
And filter density for currnt bloom filter size chosen looks has correlation with lookup speed in unexpected way.

George.