diff options
author | Kazu Hirata <kazu@google.com> | 2024-09-24 15:32:26 -0700 |
---|---|---|
committer | GitHub <noreply@github.com> | 2024-09-24 15:32:26 -0700 |
commit | 7bd4f1a0ed64aaf13e6acdafaaf50c4e7bf1d4dc (patch) | |
tree | f2594bf31e2c960840fcd99c0125085d37f3303d /llvm/lib/Object/IRObjectFile.cpp | |
parent | aeb18ebbe0a1a2fbce9b432eefed46c1d90968ea (diff) | |
download | llvm-7bd4f1a0ed64aaf13e6acdafaaf50c4e7bf1d4dc.zip llvm-7bd4f1a0ed64aaf13e6acdafaaf50c4e7bf1d4dc.tar.gz llvm-7bd4f1a0ed64aaf13e6acdafaaf50c4e7bf1d4dc.tar.bz2 |
[memprof] Use BLAKE for FrameId (#109501)
This patch uses a stronger hash function for FrameId.
Without this patch, I've observed hash collisions in fairly common
scenarios. Specifically, for a given GUID, I see three pairs of hash
collisions in the two-dimensional range 1 <= LineOffset <= 70 and
1 <= Column <= 50, which may be a bit too frequent. With the new
function, I don't see collisions at all even for a large profile.
Impact on serialization/deserialization should be as follows:
- Up to indexed memprof format Version 2, inclusive: The FrameIds
computed with the new hash function will show up as part of the
profile file. However, the deserializer only treats FrameIds as
keys (but not hash values) to retrieve Frames from the on-disk hash
table, so a change of the hash function shouldn't matter.
- For indexed memprof format Version 3, FrameIds do not show up at all
in the resulting profile file. FrameIds are only used to break ties
when we sort Frames in writeMemProfFrameArray.
Diffstat (limited to 'llvm/lib/Object/IRObjectFile.cpp')
0 files changed, 0 insertions, 0 deletions