diff options
author | Chuanqi Xu <yedeng.yd@linux.alibaba.com> | 2024-06-20 09:58:12 +0800 |
---|---|---|
committer | GitHub <noreply@github.com> | 2024-06-20 09:58:12 +0800 |
commit | ad79a14c9e5ec4a369eed4adf567c22cc029863f (patch) | |
tree | 63152ca88e9faf8274c3661af0f66b323a334f06 /llvm/lib/IR/Module.cpp | |
parent | 57778ec36c9c7e96b76a167f19dccbe00d49c9d4 (diff) | |
download | llvm-ad79a14c9e5ec4a369eed4adf567c22cc029863f.zip llvm-ad79a14c9e5ec4a369eed4adf567c22cc029863f.tar.gz llvm-ad79a14c9e5ec4a369eed4adf567c22cc029863f.tar.bz2 |
[ADT] Update hash function of uint64_t for DenseMap (#95734)
(Background: See the comment:
https://github.com/llvm/llvm-project/pull/92083#issuecomment-2168121729)
It looks like the hash function for 64bits integers are not very good:
```
static unsigned getHashValue(const unsigned long long& Val) {
return (unsigned)(Val * 37ULL);
}
```
Since the result is truncated to 32 bits. It looks like the higher 32
bits won't contribute to the result. So that `0x1'00000001` will have
the the same results to `0x2'00000001`, `0x3'00000001`, ...
Then we may meet a lot collisions in such cases. I feel it should
generally good to include higher 32 bits for hashing functions.
Not sure who's the appropriate reviewer, adding some people by
impressions.
Diffstat (limited to 'llvm/lib/IR/Module.cpp')
0 files changed, 0 insertions, 0 deletions