search for: hash_codes

...for an object 'x': > /// \code > /// using llvm::hash_value; > /// llvm::hash_code code = hash_value(x); > /// \endcode > /// > /// Also note that there are two numerical values which are reserved, and the > /// implementation ensures will never be produced for real hash_codes. These > /// can be used as sentinels within hashing data structures. > class hash_code { > size_t value; > > public: > /// \brief Default construct a hash_code. Constructs a null code. > hash_code() : value() {} > > /// \brief Form a hash code directly from a num...

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

On 02.02.14 00:48, Chandler Carruth wrote: > On Sat, Feb 1, 2014 at 8:35 AM, Stephan Tolksdorf <st at quanttec.com > <mailto:st at quanttec.com>> wrote: > > Hi, > > Currently the hashing implementation in ADT/Hashing.h produces hash > values on 32-bit platforms that differ from the lower 32-bits of the > hash values produced on 64-bit platforms.

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

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

Hi, Currently the hashing implementation in ADT/Hashing.h produces hash values on 32-bit platforms that differ from the lower 32-bits of the hash values produced on 64-bit platforms. It seems the only reason for this difference is that the uint64_t integer seed is truncated to size_t. Since the usage of uint64_t and size_t as types for seed values in the implementation is somewhat

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?

On 5/8/2013 12:38 AM, Michael Spencer 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

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

cmake -E cmake_progress_report llvm-3.8.0.src_bld_x86_64-rhel6.4-linux-gnu/CMakeFiles In file included from llvm-3.8.0.src/projects/libcxx/include/__hash_table:19:0, from llvm-3.8.0.src/projects/libcxx/src/hash.cpp:10: llvm-3.8.0.src/projects/libcxx/include/cmath:310:9: error: '::signbit' has not been declared using ::signbit; ^

Jakob and anyone else who might be interested... Base on this patch back in August, I sense some need to double check with you whether it is OK to start making a heavy use of MachineOperand TargetFlags? We do seem to have a compelling reason for it in Hexagon, and I wanted to make sure that it is OK with everyone. I plan to use it for attributing target specific info to MOs and in more general

> +  // 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 implementations of the

On Thu, May 9, 2013 at 12:04 AM, Shankar Easwaran <shankare at codeaurora.org>wrote: > On 5/8/2013 12:38 AM, Michael Spencer 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;

On May 7, 2013, at 10:38 PM, Michael 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

Hi Sergei, our use of target flags will be on immediate register operands if I am not mistaken (and if not we can always encode it as such)? I guess you are refering to the hexagon backend needing to distinguish between instances of an instruction that uses a constant value that can fit into the 4 byte of the instruction and one that encodes the immediate in an extra instruction slot (what we

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 ...

Arnold, I wanted to hear from Jacob is the original patch in question still needed, since our use of this field could surpass const extenders and could potentially include MO_Register. Jacob, Can you please comment? Thanks. Sergei --- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation > -----Original Message----- > From: Arnold