Skip to content

[ADT] Update hash function of uint64_t for DenseMap #95734

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Jun 20, 2024
Merged

[ADT] Update hash function of uint64_t for DenseMap #95734

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
c7b23d8
[ADT] Update hash function of uint64_t for DenseMap
ChuanqiXu9 Jun 17, 2024
773ade7
Update
ChuanqiXu9 Jun 17, 2024
0456725
Update
ChuanqiXu9 Jun 18, 2024
b6eac6d
Update
ChuanqiXu9 Jun 19, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 5 additions & 2 deletions llvm/include/llvm/ADT/DenseMapInfo.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -137,7 +137,10 @@ template<> struct DenseMapInfo<unsigned long> {
static inline unsigned long getTombstoneKey() { return ~0UL - 1L; }

static unsigned getHashValue(const unsigned long& Val) {
return (unsigned)(Val * 37UL);
if constexpr (sizeof(Val) == 4)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now we have densemap::detail::mix with very low latency, we can use it unconditionally for now.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's best to keep the conditional so you get the same hashing behavior if you use a different spelling for what is essentially the same type.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I'd like to keep the condition too.

return DenseMapInfo<unsigned>::getHashValue(Val);
else
return detail::combineHashValue(Val >> 32, Val);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ChuanqiXu9 To silence MSVC warnings, could we change this to:

return detail::combineHashValue(Val >> (4 * sizeof(Val)), Val);

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. You can land that directly to make the build green. But I don't understand in what cases it is a problem. I think I've already handled the case for its size is 4. I don't feel it is possible that sizeof(Val) may evaluate to 2 here.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

MSVC has a tendency to analyze additional paths such as the non-constexpr else clause - we've hit similar problems before :(

}

static bool isEqual(const unsigned long& LHS, const unsigned long& RHS) {
Expand All @@ -151,7 +154,7 @@ template<> struct DenseMapInfo<unsigned long long> {
static inline unsigned long long getTombstoneKey() { return ~0ULL - 1ULL; }

static unsigned getHashValue(const unsigned long long& Val) {
return (unsigned)(Val * 37ULL);
return detail::combineHashValue(Val >> 32, Val);
}

static bool isEqual(const unsigned long long& LHS,
Expand Down
Loading