[LLVMdev] ADT/Hashing.h on 32-bit platforms

Chandler Carruth chandlerc at google.com
Mon Feb 3 14:05:57 PST 2014


On Mon, Feb 3, 2014 at 1:46 PM, Stephan Tolksdorf <st at quanttec.com> wrote:

> I've attached a patch that makes the hashing implementation consistently
> use a 64-bit seed everywhere.  With this change the implementation should
> produce the same hash codes modulo SIZE_MAX + 1 for identical values
> independent of the platform. (Though hash_combine may still produce
> different results if the size of an argument type differs between
> platforms). I suspect the negative performance impact on 32-bit platforms
> should be small, but I didn't do any benchmarking. With atomics one could
> probably replace the thread safe local static in get_execution_seed with
> something that has a little less overhead.
>
> The patch also removes a FIXME from the set_fixed_execution_seed
> implementation and rewords the documentation string a bit, since using this
> function in a multi-threaded program requires some kind of external
> synchronization anyway.
>

Very cool. A minor comment:

   /// \brief Form a hash code directly from a numerical value.
-  hash_code(size_t value) : value(value) {}
+  ///
+  /// The argument is casted to and stored as a size_t value.
+  hash_code(uint64_t value) : value(static_cast<size_t>(value)) {}

I think it would be better to store the 64-bit value internally and reduce
to size_t when asked. That way we could (perhaps in the future) expose a
higher fidelity uint64_t extraction mechanism.

My idea is basically that the hashing code should be 64-bit input always,
and 64-bit output always, but provide easy methods for consumers which
*need* to only get size_t output to truncate safely and consistently.

Does that make sense?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140203/3598881e/attachment.html>


More information about the llvm-dev mailing list