[compiler-rt] r212801 - [msan] A comment for the chained-origin-depot hash function.
Evgeniy Stepanov
eugeni.stepanov at gmail.com
Fri Jul 11 02:09:37 PDT 2014
Author: eugenis
Date: Fri Jul 11 04:09:37 2014
New Revision: 212801
URL: http://llvm.org/viewvc/llvm-project?rev=212801&view=rev
Log:
[msan] A comment for the chained-origin-depot hash function.
Modified:
compiler-rt/trunk/lib/msan/msan_chained_origin_depot.cc
Modified: compiler-rt/trunk/lib/msan/msan_chained_origin_depot.cc
URL: http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/msan/msan_chained_origin_depot.cc?rev=212801&r1=212800&r2=212801&view=diff
==============================================================================
--- compiler-rt/trunk/lib/msan/msan_chained_origin_depot.cc (original)
+++ compiler-rt/trunk/lib/msan/msan_chained_origin_depot.cc Fri Jul 11 04:09:37 2014
@@ -19,6 +19,19 @@ namespace __msan {
struct ChainedOriginDepotDesc {
u32 here_id;
u32 prev_id;
+ /* This is murmur2 hash for the 64->32 bit case.
+ It does not behave all that well because the keys have a very biased
+ distribution (I've seen 7-element buckets with the table only 14% full).
+
+ here_id is built of
+ * (1 bits) Reserved, zero.
+ * (8 bits) Part id = bits 13..20 of the hash value of here_id's key.
+ * (23 bits) Sequential number (each part has each own sequence).
+
+ prev_id has either the same distribution as here_id (but with 3:8:21)
+ split, or one of two reserved values (-1) or (-2). Either case can
+ dominate depending on the workload.
+ */
u32 hash() const {
const u32 m = 0x5bd1e995;
const u32 seed = 0x9747b28c;
More information about the llvm-commits
mailing list