similar to: [LLVMdev] ADT/Hashing.h on 32-bit platforms

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 29 February 2012 09:35, Chandler Carruth <chandlerc at google.com> wrote: > I still think we can do more, but it's already much faster than the existing LLVM one except for the issue Tobias pointed out w/ modulo-4 key sizes. I'm going to investigate this OK, but this is a VERY big exception! Almost any non-string data anyone wants to hash will be a multiple of 4 bytes in

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

On Sun, May 11, 2014 at 8:19 AM, Stephan Tolksdorf <st at quanttec.com> wrote: > Hi, > > When clang/LLVM can't prove that a noexcept function only contains > non-throwing code, it seems to insert an explicit exception handler that > calls std::terminate. Why doesn't clang leave it to the eh personality > function to call std::terminate when an exception is thrown

Hi, When clang/llvm compiles the following sample (with -O2) it optimizes away the second comparison in test1 but not in test2. Is this handling of 'unreachable' by purpose, or is this just a shortcoming of the current optimization passes? GCC and MSVC (with the equivalent code using the __assume intrinsic) both optimize away the comparison in test2. void f1(); void f2(); void

Hi Mark, I just dug out a bug from 2006 which since 2009 seems to also have covered efforts to make better use of unreachable for optimization purposes: http://llvm.org/bugs/show_bug.cgi?id=810 I've added a comment and assigned it to you as requested. Thanks, Stephan On 24.10.13 19:05, Mark Lacey wrote: > > On Oct 24, 2013, at 5:22 AM, Stephan Tolksdorf <st at

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

On Oct 24, 2013, at 5:22 AM, Stephan Tolksdorf <st at quanttec.com> wrote: > Hi, > > When clang/llvm compiles the following sample (with -O2) it optimizes away the second comparison in test1 but not in test2. Is this handling of 'unreachable' by purpose, or is this just a shortcoming of the current optimization passes? GCC and MSVC (with the equivalent code using the

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 Thu, Mar 12, 2015 at 4:52 AM, Stephan Tolksdorf <st at quanttec.com> wrote: > > On 11.03.2015 23:02, Rui Ueyama wrote: > >> An idea to make the resolver faster would be to use a concurrent hash >> map to insert new symbols in parallel. Assuming symbols from the same >> file don't conflict each other (I think it's a valid assumption), this >> can

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

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

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

Hi, is there any way to execute scripts in R (Windows) without the script being copied to the console, so that only error messages are reported? Or to have a second console in parallel? Please. Not being able to hit the F10 button like in S-Plus seriously impairs my productivity (not only because it is slow and clutters my console history). And totally unrelated: Is there any chance that R

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

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

----- Original Message ----- > From: "İsmail Dönmez" <ismail at donmez.ws> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Monday, May 12, 2014 7:18:48 AM > Subject: Re: Lots of regtest failures on PPC64/Linux > > > Hi Hal, > > > > > > On

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

Hi How do I set the language of the GUI? With R 2.1.0 it suddenly changed to German and I want it to stay English. I couldn't find any setting to change. Regards, Stephan