search for: hash_value

...of the program has a high probability of producing a different > // hash_code for a given input. Thus their values are not stable to save or > // persist, and should only be used during the execution for the > // construction of hashing datastructures. > // > // -- 'hash_value' is a function designed to be overloaded for each > // user-defined type which wishes to be used within a hashing context. It > // should be overloaded within the user-defined type's namespace and found via > // ADL. Overloads for primitive types are provided by this library. &g...

...+ */ + +/* + * Usage: + * + * _ from CLI: + * hash.c32 path/to/list_file + * + * _ from a configuration file : + * COM32 hash.c32 + * APPEND path/to/list_file + * + * The content's format of the list_file is expected to be: + * + * md5sum path/to/file + * + * or more generally: + * + * hash_value1 path/to/file1 + * hash_value2 path/to/file2 + * hash_value3 path/to/file3 + * ... + * + * in which: + * _ 'path/to/file' + * is the file to evaluate + * + * _ 'hash_value' + * is the expected checksum value for + * the file listed in the same row. + */ + +#include...

Thanks for the feedback thus far! I've updated the header file, and enclosed a complete patch against LLVM. This passes all the regtests, and I'll be doing more thorough testing of LLVM itself with the patch. I've included some basic unit tests, but could probably do more here... Not sure it's worth delaying the initial submission though, as the best testing is to use a hash

I have spent some time examining the llvm code now, and it seems most of the hash_maps are keyed with pointers, and a few with ints. There is also one place where the keys are std::string. All these are unproblematic with the Visual Studio std_ext::hash_map since it provides hash_value functions for all these types (note, it hashes char * as pointers, not as strings - but char * is not used as a key anywhere in LLVM). This means that although the way of adding your own hashing functions is different, the default implementation works for 99% of all the cases and the ADT/HashEx...

...the ArrayRef version 'addPointers' and have it take an ArrayRef<T*>. Now, as to the 4 bytes issue, I think I can solve that with some clever template methods. > Though it is more verbose, I think it would be better to expose a template > specialization approach to getting the hash_value of T. > > /// Add a float > void add(float Data) { > addImpl( > reinterpret_cast<const uint32_t *>(&Data), > reinterpret_cast<const uint32_t *>(&Data + 1)); > } > > /// Add a double > void add(double Data) { > addImp...

...ding a comment might be in order. Similarly, I can make the ArrayRef version 'addPointers' and have it take an ArrayRef<T*>. Ah, Jay was right, I misread this code! > Though it is more verbose, I think it would be better to expose a template specialization approach to getting the hash_value of T. > > /// Add a float > void add(float Data) { > addImpl( > reinterpret_cast<const uint32_t *>(&Data), > reinterpret_cast<const uint32_t *>(&Data + 1)); > } > > /// Add a double > void add(double Data) { > addI...

Hello folks, TL;DR: This is my proposed hashing interface based on a proposed standard hashing interface. It also is implemented with a much faster and higher quality algorithm than the current one. This is an *early draft* of the code, looking for initial feedback. There has been recent interest in improving the quality and consistency of LLVM's approach to hashing. In particular, getting

...ltiple of 8, you end up not using about 90% of the slot as a direct access in an open addressing hash table. By the way, does anyone know the rationale behind using 37? In order to improve this, it could be nice to use a better hash function such as the Knuth hash which is defined as: std::size_t hash_value(std::size_t val, int p) { assert(p >= 0 && p <= 64); const std::size_t knuth = 11133510565745311; return (val * knuth) >> (64 - p); } The big advantage of this function is that is shuffles all the bits and does not suffer from the problems given above. It is also quit...

...eeded? Also, addImpl is dereferencing the pointers as uint32_t's, but there is nothing that guarantees that T is a multiple of 4 bytes. The ArrayRef version has the same problem. Though it is more verbose, I think it would be better to expose a template specialization approach to getting the hash_value of T. /// Add a float void add(float Data) { addImpl( reinterpret_cast<const uint32_t *>(&Data), reinterpret_cast<const uint32_t *>(&Data + 1)); } /// Add a double void add(double Data) { addImpl( reinterpret_cast<const uint32_t *>(&am...

...2 > =162770&view=diff > ======================================================================= > ======= > --- llvm/trunk/lib/CodeGen/MachineInstr.cpp (original) > +++ llvm/trunk/lib/CodeGen/MachineInstr.cpp Tue Aug 28 13:05:48 2012 > @@ -208,8 +208,8 @@ > hash_code llvm::hash_value(const MachineOperand &MO) { > switch (MO.getType()) { > case MachineOperand::MO_Register: > - return hash_combine(MO.getType(), MO.getTargetFlags(), > MO.getReg(), > - MO.getSubReg(), MO.isDef()); > + // Register operands don't have targe...

On Mon, Feb 13, 2012 at 1:22 AM, Jay Foad <jay.foad at gmail.com> wrote: > On 13 February 2012 00:59, Talin <viridia at gmail.com> wrote: > > Here's my latest version of Hashing.h, which I propose to add to > llvm/ADT. > > Comments welcome and encouraged. > > > /// Adapted from MurmurHash2 by Austin Appleby > > Just out of curiosity, why not

...#define VIRTIO_NET_F_STANDBY 62 /* Act as standby for another device > @@ -144,6 +145,23 @@ struct virtio_net_hdr_v1 { > __virtio16 num_buffers; /* Number of merged rx buffers */ > }; > > +struct virtio_net_hdr_v1_hash { > + struct virtio_net_hdr_v1 hdr; > + __virtio32 hash_value; > +#define VIRTIO_NET_HASH_REPORT_NONE 0 > +#define VIRTIO_NET_HASH_REPORT_IPv4 1 > +#define VIRTIO_NET_HASH_REPORT_TCPv4 2 > +#define VIRTIO_NET_HASH_REPORT_UDPv4 3 > +#define VIRTIO_NET_HASH_REPORT_IPv6 4 > +#define VIRTIO_NE...

...diff >> ======================================================================= >> ======= >> --- llvm/trunk/lib/CodeGen/MachineInstr.cpp (original) >> +++ llvm/trunk/lib/CodeGen/MachineInstr.cpp Tue Aug 28 13:05:48 2012 >> @@ -208,8 +208,8 @@ >> hash_code llvm::hash_value(const MachineOperand &MO) { >> switch (MO.getType()) { >> case MachineOperand::MO_Register: >> - return hash_combine(MO.getType(), MO.getTargetFlags(), >> MO.getReg(), >> - MO.getSubReg(), MO.isDef()); >> + // Register opera...

...* + * Normally half nums will be moved. But we have to make sure + * that the xattr with same hash value is stored in the same + * bucket. If all the xattrs in this bucket has the same hash + * value, the new bucket will be initialized as an empty one + * and the first_hash will be initialized as (hash_value+1). */ -static int ocfs2_half_xattr_bucket(struct inode *inode, - handle_t *handle, - u64 blk, - u64 new_blk, - u32 *first_hash, - int new_bucket_head) +static int ocfs2_divide_xattr_bucket(struct inode *inode, + handle_t *handle, + u64 blk, + u6...

...does only add new members to virtio_net_hdr_mrg_rxbuf, so the spec should only add new members, otherwise there will be compatibility problems in struct virtio_net_hdr_v1_hash structure. struct virtio_net_hdr_v1_hash { struct virtio_net_hdr_v1 hdr; /*same size as virtio_net_hdr*/ [...] __le32 hash_value; /*new member*/ __le16 hash_report; /*new member*/ __le16 padding; /*new member*/ }; virtio_net_hdr_v1_hash cannot use virtio_net_hdr as the first member, because in virtio_net_hdr_v1, csum_start and csum_offset are stored in union as a structure, and virtio_net_hdr cannot be used instead. st...

This series introduce virtio-net features VIRTIO_NET_F_RSC_EXT, VIRTIO_NET_F_RSS and VIRTIO_NET_F_HASH_REPORT. Changes from v3: reformatted structure in patch 1 Yuri Benditovich (3): virtio-net: Introduce extended RSC feature virtio-net: Introduce RSS receive steering feature virtio-net: Introduce hash report feature include/uapi/linux/virtio_net.h | 102 ++++++++++++++++++++++++++++++--

...dereferencing the pointers as > uint32_t's, but there is nothing that guarantees that T is a multiple of 4 > bytes.  The ArrayRef version has the same problem. > > Though it is more verbose, I think it would be better to expose a template > specialization approach to getting the hash_value of T. > >   /// Add a float >   void add(float Data) { >     addImpl( >       reinterpret_cast<const uint32_t *>(&Data), >       reinterpret_cast<const uint32_t *>(&Data + 1)); >   } > >   /// Add a double >   void add(double Data) { >     addImp...

...date'' /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.11.2/lib/action_controller/session/active_record_store.rb:307:in `close'' /usr/local/lib/ruby/1.8/cgi/session.rb:166:in `callback'' /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/base.rb:833:in `hash_value'' /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.11.2/lib/action_controller/routing.rb:108:in `default_check'' /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.11.2/lib/action_controller/routing.rb:124:in `write_dropout_generation'' /usr/local/lib/ruby/gems/1.8/gems/actionpa...

// -- 'hash_code' class is an opaque type representing the hash code for some // data. It is the intended product of hashing, and can be used to implement vs. // -- 'hash_value' is a function designed to be overloaded for each // user-defined type which wishes to be used within a hashing context. It The first paragraph has a hanging indent but the second and third don't. // benchmarked at over 8.5 GiB/s for large keys, and <20 cycles/ Trailing punctuation....

...=========================================== > >> == > >> ======= > >> --- llvm/trunk/lib/CodeGen/MachineInstr.cpp (original) > >> +++ llvm/trunk/lib/CodeGen/MachineInstr.cpp Tue Aug 28 13:05:48 2012 > >> @@ -208,8 +208,8 @@ > >> hash_code llvm::hash_value(const MachineOperand &MO) { > >> switch (MO.getType()) { > >> case MachineOperand::MO_Register: > >> - return hash_combine(MO.getType(), MO.getTargetFlags(), > >> MO.getReg(), > >> - MO.getSubReg(), MO.isDef()); > &...