[PATCH] D158250: [IR] Add more details to StructuralHash
Aiden Grossman via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon Aug 21 15:50:26 PDT 2023
aidengrossman added inline comments.
================
Comment at: llvm/lib/IR/StructuralHash.cpp:48
+ // get decent coverage over the function.
+ if (ConstantInt *ConstInt = dyn_cast<ConstantInt>(Operand)) {
+ if (ConstInt->getBitWidth() <= 64) {
----------------
aeubanks wrote:
> we really shouldn't have to re-implement `llvm::hash_value`. IIUC the reason we're not is because 32-bit vs 64-bit hashes are different which causes MergeFunctions to act differently because it sorts hashes. but IMO MergeFunctions shouldn't be sorting by hash, that's kinda bad. I think we should go back to the original version of https://reviews.llvm.org/D158217 and fix MergeFunctions to be more deterministic and not rely on hash values. It seems like we're just currently lucky in that the hashes for test cases in MergeFunctions are ordered consistently between 32/64 bit.
I agree that it shouldn't be sorting by hash, but I'd rather not touch that if I don't have to. When I relanded that differential in 64da0be1fc06ee2199bd27c980736986e0eccd9d I updated it to use what `MergeFunctions` did originally and use `hash_16_bytes` along with a `uint64_t` rather than `size_t` (forgot to update the differential with the changes). The MergeFunction test was consistent before https://reviews.llvm.org/D158217 as they just directly called `hash_16_bytes` and stored everything as a `uint64_t`.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D158250/new/
https://reviews.llvm.org/D158250
More information about the llvm-commits
mailing list