Displaying 7 results from an estimated 7 matches for "generalhash".
2012 Feb 18
3
[LLVMdev] We need better hashing
...39;t matter however, because hashing on
> + /// pointer values is inherently unstable.
>
> This makes perfect sense.
>
> It should, as the comment was copied verbatim from FoldingSetNodeID :)
> + /// Add an ArrayRef of arbitrary data.
> + template<typename T>
> + GeneralHash& add(ArrayRef<T> ArrayVal) {
> + addBits(ArrayVal.begin(), ArrayVal.end());
> + return *this;
> + }
>
> Doesn't this have the same host-specificity problem, except that it will
> cause things that *are* stable to vary, such as arrays of char, or is the
> al...
2012 Feb 17
0
[LLVMdev] We need better hashing
.../// Note: this adds pointers to the hash using sizes and endianness that
+ /// depend on the host. It doesn't matter however, because hashing on
+ /// pointer values is inherently unstable.
This makes perfect sense.
+ /// Add an ArrayRef of arbitrary data.
+ template<typename T>
+ GeneralHash& add(ArrayRef<T> ArrayVal) {
+ addBits(ArrayVal.begin(), ArrayVal.end());
+ return *this;
+ }
Doesn't this have the same host-specificity problem, except that it will cause things that *are* stable to vary, such as arrays of char, or is the alignment check enough?
+ /// Add...
2012 Feb 18
0
[LLVMdev] We need better hashing
On Feb 18, 2012, at 1:11 AM, Talin wrote:
> + /// Add an ArrayRef of arbitrary data.
> + template<typename T>
> + GeneralHash& add(ArrayRef<T> ArrayVal) {
> + addBits(ArrayVal.begin(), ArrayVal.end());
> + return *this;
> + }
>
> Doesn't this have the same host-specificity problem, except that it will cause things that *are* stable to vary, such as arrays of char, or is the alignment c...
2012 Feb 17
4
[LLVMdev] We need better hashing
OK here's a patch with the latest, including unit tests. I've also tried to
make the comments clear that this is intended for the case of "generic" key
types, where you are either hashing multiple data types together, or you
don't know in advance what the data type will be - for cases such as
strings where a tailored algorithm is available, you should use that
instead of
2012 Feb 21
5
[LLVMdev] buildbot failure in LLVM on clang-x86_64-debian-fnt
...----------------------
r151049 | foad | 2012-02-21 09:25:52 +0000 (Tue, 21 Feb 2012) | 6 lines
Changed paths:
M /llvm/trunk/lib/VMCore/LLVMContextImpl.h
M /llvm/trunk/lib/VMCore/Type.cpp
PR1210: make uniquing of struct and function types more efficient by
using a DenseMap and Talin's new GeneralHash, avoiding the need for a
temporary std::vector on every lookup.
Patch by Meador Inge!
------------------------------------------------------------------------
... but I can't reproduce the failures on my machine. I'm also running
x86_64 Linux, I've checked out the same revision of
ll...
2012 Feb 21
0
[LLVMdev] buildbot failure in LLVM on clang-x86_64-debian-fnt
...049 | foad | 2012-02-21 09:25:52 +0000 (Tue, 21 Feb 2012) | 6 lines
> Changed paths:
> M /llvm/trunk/lib/VMCore/LLVMContextImpl.h
> M /llvm/trunk/lib/VMCore/Type.cpp
>
> PR1210: make uniquing of struct and function types more efficient by
> using a DenseMap and Talin's new GeneralHash, avoiding the need for a
> temporary std::vector on every lookup.
>
> Patch by Meador Inge!
>
> ------------------------------------------------------------------------
>
> ... but I can't reproduce the failures on my machine. I'm also running
> x86_64 Linux, I'v...
2012 Feb 21
0
[LLVMdev] buildbot failure in LLVM on clang-x86_64-debian-fnt
...049 | foad | 2012-02-21 09:25:52 +0000 (Tue, 21 Feb 2012) | 6 lines
> Changed paths:
> M /llvm/trunk/lib/VMCore/LLVMContextImpl.h
> M /llvm/trunk/lib/VMCore/Type.cpp
>
> PR1210: make uniquing of struct and function types more efficient by
> using a DenseMap and Talin's new GeneralHash, avoiding the need for a
> temporary std::vector on every lookup.
>
> Patch by Meador Inge!
>
> ------------------------------------------------------------------------
>
> ... but I can't reproduce the failures on my machine. I'm also running
> x86_64 Linux, I'v...