search for: hash_cod

...defined types. This > // interface was originally proposed in N3333[1] and is currently under review > // for inclusion in a future TR and/or standard. > // > // The primary interfaces provide are comprised of one type and three functions: "provided" > // > // -- '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 > // hash tables, checksumming, and other common uses of hashes. It is not an > // integer type (although it can be converted to one)...

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

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

...: Was this difference deliberately introduced as a > performance optimization for 32-bit code, or is this maybe just an > implementation artifact? > > I also noted that the implementation relies on implicit conversions > from uint64_t to size_t in several places where hash_code values are > returned, which may trigger compiler warnings on 32-bit platforms. > > > Almost all of this was largely incidental on my part. I didn't spend a > lot of time tuning the 32-bit platform performance. If you have ideas > that you think would make things better,...

On Tue, May 7, 2013 at 10:08 PM, Nick Kledzik <kledzik at apple.com> wrote: > Shankar, > > Do you mean add a method like: > > virtual unsigned contentHash() const = 0; > > or maybe: > > virtual llvm::hash_code contentHash() const = 0 > > to lld::DefinedAtom? That seems good to me. We just need to figure out > what should happen with atoms not intended to be merged. Should the method > assert? In the case where we want there to be a hash available, is it > computed lazily? > > R...

// -- '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 contex...

...ewhat inconsistent, I'm wondering: Was this difference deliberately introduced as a performance optimization for 32-bit code, or is this maybe just an implementation artifact? I also noted that the implementation relies on implicit conversions from uint64_t to size_t in several places where hash_code values are returned, which may trigger compiler warnings on 32-bit platforms. - Stephan

Shankar, Do you mean add a method like: virtual unsigned contentHash() const = 0; or maybe: virtual llvm::hash_code contentHash() const = 0 to lld::DefinedAtom? That seems good to me. We just need to figure out what should happen with atoms not intended to be merged. Should the method assert? In the case where we want there to be a hash available, is it computed lazily? Regarding the NativeReader/Nativ...

...r wrote: > On Tue, May 7, 2013 at 10:08 PM, Nick Kledzik <kledzik at apple.com> wrote: > >> Shankar, >> >> Do you mean add a method like: >> >> virtual unsigned contentHash() const = 0; >> >> or maybe: >> >> virtual llvm::hash_code contentHash() const = 0 We could use a crypto hash too with the function prototype that looks like :- virtual lld::crypto::sha256 contentHash() const = 0 >> to lld::DefinedAtom? That seems good to me. We just need to figure out >> what should happen with atoms not intended...

Hi Nick, Can we add a atomContentHash for DefinedAtoms when the atoms are being created. This can essentially speed up comparisons of atoms especially for * ICF (Identical code folding) * Section groups (to identify similiar sections) Not sure where else this would help. This would essentially be used only by the Reader and the Resolver. There would be no change to the

...projects/libcxx/include/functional:475:0, from llvm-3.8.0.src/projects/libcxx/include/experimental/optional:144, from llvm-3.8.0.src/projects/libcxx/src/optional.cpp:10: llvm-3.8.0.src/projects/libcxx/include/typeinfo: In member function 'size_t std::type_info::hash_code() const': llvm-3.8.0.src/projects/libcxx/include/typeinfo:116:62: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] {return *reinterpret_cast<const size_t*>(&__type_name);}...

...;r1=162769&r2 > =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 do...

> +  // Helper for test code to print hash codes. > +  void PrintTo(const hash_code &code, ::std::ostream *os) { > > What's with the extra leading :: before std::? Have you ever tried: namespace foo { class std {}; } using namespace foo; #include <vector> Well, I'm not sure that Chandler is guarding against this possibility, but most library implementa...

...10:08 PM, Nick Kledzik <kledzik at apple.com> wrote: >> >> Shankar, >>> >>> Do you mean add a method like: >>> >>> virtual unsigned contentHash() const = 0; >>> >>> or maybe: >>> >>> virtual llvm::hash_code contentHash() const = 0 >>> >> We could use a crypto hash too with the function prototype that looks > like :- > > virtual lld::crypto::sha256 contentHash() const = 0 I'd use SHA128 or MD5 as the linker does not handle hostile input. I think as long as it's c...

...Spencer <bigcheesegs at gmail.com> wrote: > On Tue, May 7, 2013 at 10:08 PM, Nick Kledzik <kledzik at apple.com> wrote: > Shankar, > > Do you mean add a method like: > > virtual unsigned contentHash() const = 0; > > or maybe: > > virtual llvm::hash_code contentHash() const = 0 > > to lld::DefinedAtom? That seems good to me. We just need to figure out what should happen with atoms not intended to be merged. Should the method assert? In the case where we want there to be a hash available, is it computed lazily? > > Regarding the...

...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()); >> +...

Greetings! I have been building llvm-3.6.x, 3.7.1 and 3.7.2 with (glibc-2.12.1, binutils-2.24, gcc-4.9.2) almost same set if CMake flags. However while building LLVM-3.8.0 using same CMake flags I am observing projects/libcxx/include/cmath errors... ...'::signbit' has not been declared ...'::fpclassify' has not been declared ...'::isfinite' has not been declared ...

...=========================================================== > >> == > >> ======= > >> --- 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(), M...