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

[Rafael Avila de Espindola via llvm-commits]

George Rimar <grimar at accesssoftek.com> writes:

>>> I feel like this change looks a bit too arbitrary. If we can prove that it
>>> is in general an improvement, I'm fine with this change, but even George's
>>> experiment shows that 11 may not be an optimal number.
>>>
>>> Probably what we should do is to try different shift2 numbers to see if
>>> which one yields the best result on the fly. I'll try to see if this isn't
>>> too slow.
>>
>>Note that his computed score doesn't correlate with performance in all
>>cases. In particular I got bad results with 1, but that has a high
>>score.
>>
>>Cheers,
>>Rafael
>
> Yeah, it has a high score for test using random symbol names.
> I had bad results with 1 when run llvm-check too.
>
> Though the patch which calculates the score with the same algoritm in runtime
> worked good for llvm-check. I did not check which values it normally selects for llvm case.

If I understand it correctly, a patch to maximize your score that tries
every shift2 value will effectively maximize how many set bits we have
in the bloom filter, no?

It almost feels that that is the opposite of what we want.The more 0s that
are left in the bloom filter the more likely it is that the dynamic
linker can skip this .so at runtime.

The value 0 feels like a bad special case because then there is only one
bit, which makes a hit more likely.

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