[PATCH] D109024: [Support] Automatically support `hash_value` when `HashBuilder` support is available.
Duncan P. N. Exon Smith via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Sep 2 12:53:42 PDT 2021
dexonsmith added inline comments.
================
Comment at: llvm/include/llvm/Support/HashBuilder.h:92-97
+ /// Trait to indicate whether a type's bits can be hashed directly (after
+ /// endianness correction).
+ template <typename U>
+ struct IsHashableData
+ : std::integral_constant<bool, is_integral_or_enum<U>::value> {};
+
----------------
Noticing now that this trait is independent of HashBuilder's template parameters. I suggest moving it outside HashBuilder in a prep commit (probably doesn't need a review), maybe into a detail namespace like `llvm::hashbuilder_detail`.
================
Comment at: llvm/include/llvm/Support/HashBuilder.h:405
+
+class HashCodeHasher {
+ public:
----------------
arames wrote:
> This was suggested as part of https://reviews.llvm.org/D102943.
>
> A couple things to consider:
>
> The default implementation of `hash_value` would always go through `ArrayRef<uint8_t>`:
> This may be less efficient than an explicit implementation. IMO that's ok, since it can be explicitly implemented if performance is an issue.
> The behavior may differ from what would happen with `hash_value` and co. For example `hash_value` for integral and enum types casts to `uint64_t` to guarantee `(char)1` and `(int)1` have the same hash. Again, IMO that's ok. We are talking about generating hashes for custom structures. If this behavior is required, it can be explicitly implemented.
>
> Using `hash_value` with that mechanism requires calling `llvm::hash_value` or (`using llvm::hash_value`) explicitly. I need to brush up on ADL and template functions (I think that's what involved here). Again, that looks acceptable to me.
>
> What do you think ?
One option would be to throw `HashCodeHasher` and `HashCodeHashBuilder` into a detail namespace to discourage anyone trying to use `HashCodeHashBuilder` directly. There's an asymmetric relationship:
- Objects get `hash_value` for free if they add `HashBuilder` support.
- ... but using `HashBuilder<HashCodeHasher>` directly isn't very useful, since `HashCodeHashBuilder().add(X).getHasher().Code` is not guaranteed to match `hash_value(X)`.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D109024/new/
https://reviews.llvm.org/D109024
More information about the llvm-commits
mailing list