third_party/re2/util/hash.cc

   1 // Modified by Russ Cox to add "namespace re2".
   2 // Also threw away all but hashword and hashword2.
   3 // http://burtleburtle.net/bob/c/lookup3.c
   4
   5 /*
   6 -------------------------------------------------------------------------------
   7 lookup3.c, by Bob Jenkins, May 2006, Public Domain.
   8
   9 These are functions for producing 32-bit hashes for hash table lookup.
  10 hashword(), hashlittle(), hashlittle2(), hashbig(), mix(), and final()
  11 are externally useful functions.  Routines to test the hash are included
  12 if SELF_TEST is defined.  You can use this free for any purpose.  It's in
  13 the public domain.  It has no warranty.
  14
  15 You probably want to use hashlittle().  hashlittle() and hashbig()
  16 hash byte arrays.  hashlittle() is is faster than hashbig() on
  17 little-endian machines.  Intel and AMD are little-endian machines.
  18 On second thought, you probably want hashlittle2(), which is identical to
  19 hashlittle() except it returns two 32-bit hashes for the price of one.
  20 You could implement hashbig2() if you wanted but I haven't bothered here.
  21
  22 If you want to find a hash of, say, exactly 7 integers, do
  23   a = i1;  b = i2;  c = i3;
  24   mix(a,b,c);
  25   a += i4; b += i5; c += i6;
  26   mix(a,b,c);
  27   a += i7;
  28   final(a,b,c);
  29 then use c as the hash value.  If you have a variable length array of
  30 4-byte integers to hash, use hashword().  If you have a byte array (like
  31 a character string), use hashlittle().  If you have several byte arrays, or
  32 a mix of things, see the comments above hashlittle().
  33
  34 Why is this so big?  I read 12 bytes at a time into 3 4-byte integers,
  35 then mix those integers.  This is fast (you can do a lot more thorough
  36 mixing with 12*3 instructions on 3 integers than you can with 3 instructions
  37 on 1 byte), but shoehorning those bytes into integers efficiently is messy.
  38 -------------------------------------------------------------------------------
  39 */
  40
  41 #include "util/util.h"
  42
  43 #define rot(x,k) (((x)<<(k)) | ((x)>>(32-(k))))
  44
  45 /*
  46 -------------------------------------------------------------------------------
  47 mix -- mix 3 32-bit values reversibly.
  48
  49 This is reversible, so any information in (a,b,c) before mix() is
  50 still in (a,b,c) after mix().
  51
  52 If four pairs of (a,b,c) inputs are run through mix(), or through
  53 mix() in reverse, there are at least 32 bits of the output that
  54 are sometimes the same for one pair and different for another pair.
  55 This was tested for:
  56 * pairs that differed by one bit, by two bits, in any combination
  57   of top bits of (a,b,c), or in any combination of bottom bits of
  58   (a,b,c).
  59 * "differ" is defined as +, -, ^, or ~^.  For + and -, I transformed
  60   the output delta to a Gray code (a^(a>>1)) so a string of 1's (as
  61   is commonly produced by subtraction) look like a single 1-bit
  62   difference.
  63 * the base values were pseudorandom, all zero but one bit set, or
  64   all zero plus a counter that starts at zero.
  65
  66 Some k values for my "a-=c; a^=rot(c,k); c+=b;" arrangement that
  67 satisfy this are
  68     4  6  8 16 19  4
  69     9 15  3 18 27 15
  70    14  9  3  7 17  3
  71 Well, "9 15 3 18 27 15" didn't quite get 32 bits diffing
  72 for "differ" defined as + with a one-bit base and a two-bit delta.  I
  73 used http://burtleburtle.net/bob/hash/avalanche.html to choose
  74 the operations, constants, and arrangements of the variables.
  75
  76 This does not achieve avalanche.  There are input bits of (a,b,c)
  77 that fail to affect some output bits of (a,b,c), especially of a.  The
  78 most thoroughly mixed value is c, but it doesn't really even achieve
  79 avalanche in c.
  80
  81 This allows some parallelism.  Read-after-writes are good at doubling
  82 the number of bits affected, so the goal of mixing pulls in the opposite
  83 direction as the goal of parallelism.  I did what I could.  Rotates
  84 seem to cost as much as shifts on every machine I could lay my hands
  85 on, and rotates are much kinder to the top and bottom bits, so I used
  86 rotates.
  87 -------------------------------------------------------------------------------
  88 */
  89 #define mix(a,b,c) \
  90 { \
  91   a -= c;  a ^= rot(c, 4);  c += b; \
  92   b -= a;  b ^= rot(a, 6);  a += c; \
  93   c -= b;  c ^= rot(b, 8);  b += a; \
  94   a -= c;  a ^= rot(c,16);  c += b; \
  95   b -= a;  b ^= rot(a,19);  a += c; \
  96   c -= b;  c ^= rot(b, 4);  b += a; \
  97 }
  98
  99 /*
 100 -------------------------------------------------------------------------------
 101 final -- final mixing of 3 32-bit values (a,b,c) into c
 102
 103 Pairs of (a,b,c) values differing in only a few bits will usually
 104 produce values of c that look totally different.  This was tested for
 105 * pairs that differed by one bit, by two bits, in any combination
 106   of top bits of (a,b,c), or in any combination of bottom bits of
 107   (a,b,c).
 108 * "differ" is defined as +, -, ^, or ~^.  For + and -, I transformed
 109   the output delta to a Gray code (a^(a>>1)) so a string of 1's (as
 110   is commonly produced by subtraction) look like a single 1-bit
 111   difference.
 112 * the base values were pseudorandom, all zero but one bit set, or
 113   all zero plus a counter that starts at zero.
 114
 115 These constants passed:
 116  14 11 25 16 4 14 24
 117  12 14 25 16 4 14 24
 118 and these came close:
 119   4  8 15 26 3 22 24
 120  10  8 15 26 3 22 24
 121  11  8 15 26 3 22 24
 122 -------------------------------------------------------------------------------
 123 */
 124 #define final(a,b,c) \
 125 { \
 126   c ^= b; c -= rot(b,14); \
 127   a ^= c; a -= rot(c,11); \
 128   b ^= a; b -= rot(a,25); \
 129   c ^= b; c -= rot(b,16); \
 130   a ^= c; a -= rot(c,4);  \
 131   b ^= a; b -= rot(a,14); \
 132   c ^= b; c -= rot(b,24); \
 133 }
 134
 135 namespace re2 {
 136
 137 /*
 138 --------------------------------------------------------------------
 139  This works on all machines.  To be useful, it requires
 140  -- that the key be an array of uint32_t's, and
 141  -- that the length be the number of uint32_t's in the key
 142
 143  The function hashword() is identical to hashlittle() on little-endian
 144  machines, and identical to hashbig() on big-endian machines,
 145  except that the length has to be measured in uint32_ts rather than in
 146  bytes.  hashlittle() is more complicated than hashword() only because
 147  hashlittle() has to dance around fitting the key bytes into registers.
 148 --------------------------------------------------------------------
 149 */
 150 uint32 hashword(
 151 const uint32 *k,                   /* the key, an array of uint32_t values */
 152 size_t          length,               /* the length of the key, in uint32_ts */
 153 uint32        initval)         /* the previous hash, or an arbitrary value */
 154 {
 155   uint32_t a,b,c;
 156
 157   /* Set up the internal state */
 158   a = b = c = 0xdeadbeef + (((uint32_t)length)<<2) + initval;
 159
 160   /*------------------------------------------------- handle most of the key */
 161   while (length > 3)
 162   {
 163     a += k[0];
 164     b += k[1];
 165     c += k[2];
 166     mix(a,b,c);
 167     length -= 3;
 168     k += 3;
 169   }
 170
 171   /*------------------------------------------- handle the last 3 uint32_t's */
 172   switch(length)                     /* all the case statements fall through */
 173   {
 174   case 3 : c+=k[2];
 175   case 2 : b+=k[1];
 176   case 1 : a+=k[0];
 177     final(a,b,c);
 178   case 0:     /* case 0: nothing left to add */
 179     break;
 180   }
 181   /*------------------------------------------------------ report the result */
 182   return c;
 183 }
 184
 185
 186 /*
 187 --------------------------------------------------------------------
 188 hashword2() -- same as hashword(), but take two seeds and return two
 189 32-bit values.  pc and pb must both be nonnull, and *pc and *pb must
 190 both be initialized with seeds.  If you pass in (*pb)==0, the output
 191 (*pc) will be the same as the return value from hashword().
 192 --------------------------------------------------------------------
 193 */
 194 void hashword2 (
 195 const uint32 *k,                   /* the key, an array of uint32_t values */
 196 size_t          length,               /* the length of the key, in uint32_ts */
 197 uint32       *pc,                      /* IN: seed OUT: primary hash value */
 198 uint32       *pb)               /* IN: more seed OUT: secondary hash value */
 199 {
 200   uint32_t a,b,c;
 201
 202   /* Set up the internal state */
 203   a = b = c = 0xdeadbeef + ((uint32_t)(length<<2)) + *pc;
 204   c += *pb;
 205
 206   /*------------------------------------------------- handle most of the key */
 207   while (length > 3)
 208   {
 209     a += k[0];
 210     b += k[1];
 211     c += k[2];
 212     mix(a,b,c);
 213     length -= 3;
 214     k += 3;
 215   }
 216
 217   /*------------------------------------------- handle the last 3 uint32_t's */
 218   switch(length)                     /* all the case statements fall through */
 219   {
 220   case 3 : c+=k[2];
 221   case 2 : b+=k[1];
 222   case 1 : a+=k[0];
 223     final(a,b,c);
 224   case 0:     /* case 0: nothing left to add */
 225     break;
 226   }
 227   /*------------------------------------------------------ report the result */
 228   *pc=c; *pb=b;
 229 }
 230
 231 }  // namespace re2