search for: foldingsetnodeid

....125) I downloaded both the top of tree via svn I ran ./configure make make[1]: Entering directory `/cygdrive/c/llvm/lib/Support' llvm[1]: Compiling APFloat.cpp for Debug build llvm[1]: Compiling APInt.cpp for Debug build APInt.cpp: In member function `void llvm::APInt::Profile(llvm::FoldingSetNodeID&) const': APInt.cpp:170: error: call of overloaded `AddInteger(const uint32_t&)' is ambiguous /cygdrive/c/llvm/include/llvm/ADT/FoldingSet.h:216: note: candidates are: void llvm::FoldingSetNodeID::AddInteger(int) /cygdrive/c/llvm/include/llvm/ADT/FoldingSet.h:217: note: void llvm::...

...e via svn > I ran ./configure > make > > make[1]: Entering directory `/cygdrive/c/llvm/lib/Support' > llvm[1]: Compiling APFloat.cpp for Debug build > llvm[1]: Compiling APInt.cpp for Debug build > APInt.cpp: In member function `void > llvm::APInt::Profile(llvm::FoldingSetNodeID&) const': > APInt.cpp:170: error: call of overloaded `AddInteger(const uint32_t&)' > is ambiguous > /cygdrive/c/llvm/include/llvm/ADT/FoldingSet.h:216: note: candidates > are: void llvm::FoldingSetNodeID::AddInteger(int) > /cygdrive/c/llvm/include/llvm/ADT/FoldingSet....

Hi, While profiling LLVM using my test-cases with huge MBBs, I noticed that FoldingSetNodeID operations (ComputeHash,insertion,etc) may become really inefficient for the nodes, which have very many operands. I can give you an example of what is meant by "very many". In my test-case (you can fetch it from here http://llvm.org/bugs/attachment.cgi?id=1275), which is just one HUG...

...into CSE maps can be avoided alltogether? But may be I'm wrong... - Roman ----- Ursprüngliche Mail ---- Von: Chris Lattner <sabre at nondot.org> An: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> Gesendet: Donnerstag, den 24. April 2008, 02:07:55 Uhr Betreff: Re: [LLVMdev] FoldingSetNodeID operations inefficiency On Wed, 23 Apr 2008, Roman Levenstein wrote: > Hi, > > While profiling LLVM using my test-cases with huge MBBs, I noticed that > FoldingSetNodeID operations (ComputeHash,insertion,etc) may become > really inefficient for the nodes, which have very many operan...

..., Thanks for commenting on this topic. See my comments in-line. ----- Ursprüngliche Mail ---- > Von: Dan Gohman <gohman at apple.com> > An: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Gesendet: Mittwoch, den 30. April 2008, 21:38:26 Uhr > Betreff: Re: [LLVMdev] FoldingSetNodeID operations inefficiency > > > On Apr 28, 2008, at 6:21 AM, Roman Levenstein wrote: > > > Hi Chris, > > > > Your were totally right with your suggestion. > > > > I have implemented the code that : > > > > a) does not merge multiple TokenFactor...

...chTools/LLVM/2.3/obj2.3/lib/System' make[1]: Entering directory `/home/czhao/ResearchTools/LLVM/2.3/obj2.3/lib/Support' llvm[1]: Compiling APInt.cpp for Release build /home/czhao/ResearchTools/LLVM/2.3/llvm-2.3/lib/Support/APInt.cpp: In member function 'void llvm::APInt::Profile(llvm::FoldingSetNodeID&) const': /home/czhao/ResearchTools/LLVM/2.3/llvm-2.3/lib/Support/APInt.cpp:170: error: call of overloaded 'AddInteger(const uint32_t&)' is ambiguous /home/czhao/ResearchTools/LLVM/2.3/llvm-2.3/include/llvm/ADT/FoldingSet.h:216: note: candidates are: void llvm::FoldingSetNodeI...

The current implementation is: void FoldingSetNodeID::AddInteger(unsigned long long I) { AddInteger(unsigned(I)); if ((uint64_t)(int)I != I) Bits.push_back(unsigned(I >> 32)); } (uint64_t)(int)I first truncates I to signed int, which causes the second cast to sign extend the value to 64 bits. The problem is that if the 31st bit of the...

While I've not reviewed the patch in too much detail, it looks promising. Can you run some end-to-end benchmarks to make sure that cache pressure in the full program or other variables not accounted for in a micro-benchmark don't dominate performance? Specifically the nightly tester includes a number of real programs and machinery to measure total compile time. On Sat, Feb 6, 2010 at 7:09

...generation. Therefore any help is highly appreciated. Thanks, Roman ----- Ursprüngliche Mail ---- Von: Roman Levenstein <romixlev at yahoo.com> An: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> Gesendet: Donnerstag, den 24. April 2008, 08:33:25 Uhr Betreff: Re: [LLVMdev] FoldingSetNodeID operations inefficiency Hi Chris, This is a good idea and I started thinking in that direction already. But what I don't quite understand the TFs, how TFs are formed and which rules they should obey to. For example now: > PendingLoads created by the SelectionDAGLowering::getLoadFrom and...

...googlepages.com/ http://en.wikipedia.org/wiki/MurmurHash http://www.codeproject.com/KB/recipes/hash_functions.aspx as well as in the patch description itself. Patch and benchmark attached. Gregory -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-FoldingSetNodeID-use-MurmurHash2-instead-of-SuperFas.patch Type: text/x-diff Size: 4202 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100206/b1f04413/attachment.patch> -------------- next part -------------- A non-text attachment was scrubbed... Name: hash_bench.c Type...

On Aug 14, 2008, at 9:49 PM, Andy Kitchen wrote: FYI, all posts to llvmdev are moderated until the person posts something sensible. This is a PITA for me (llvm mailing lists get dozens of spams a day which require moderation), but is generally very effective. Since Andy had already posted something sensible, he was on the whitelist. However, he just lost the ability to post to llvmdev

On 2010-02-06 17:09, Gregory Petrosyan wrote: > Some additional info can be found at: > > http://murmurhash.googlepages.com/ > http://en.wikipedia.org/wiki/MurmurHash > http://www.codeproject.com/KB/recipes/hash_functions.aspx > > as well as in the patch description itself. Patch and benchmark attached. > > +/// This version additionally assumes that 'len %

On Feb 7, 2010, at 1:03 PM, Gregory Petrosyan wrote: > On Sat, Feb 06, 2010 at 04:51:15PM -0800, Chandler Carruth wrote: >> While I've not reviewed the patch in too much detail, it looks >> promising. Can you run some end-to-end benchmarks to make sure that >> cache pressure in the full program or other variables not accounted >> for in a micro-benchmark don't

...706 wall clock) This table was obtaind by running 3 times 'make TEST=nightly report.html -j2 && l Output/ | grep info | xargs cat | grep 'Total Execution Time' >> timings && make clean' or something like that, on MultiSource/Applications/ClamAV. It looks like FoldingSetNodeID is not the most performance-critical part of LLVM, but changing the hash algorithm help a bit. Gregory

LLVM currently has a bunch of different hashing algorithms scattered throughout the code base. There's also a number of places in the code where a FoldingSetNodeID is created for the purpose of calculating a hash, and then discarded. From an efficiency standpoint, this isn't all that bad unless the number of individual items being hashed > 32, at which point the SmallVector overflows and memory is allocated. I personally want to see a better approach...

I set up a Facebook profile where I can post my pictures, videos and events and I want to add you as a friend so you can see it. First, you need to join Facebook! Once you join, you can also create your own profile. Thanks, Andy Here's the link: http://www.facebook.com/p.php?i=612598021&k=63FYZWQ6WVVM5FEIWDV2PT&r&v=2 ___________________ This e-mail may contain promotional

...opies of hash functions. So feedback would be nice. On Tue, Feb 7, 2012 at 10:58 PM, Talin <viridia at gmail.com> wrote: > LLVM currently has a bunch of different hashing algorithms scattered > throughout the code base. > > There's also a number of places in the code where a FoldingSetNodeID is > created for the purpose of calculating a hash, and then discarded. From an > efficiency standpoint, this isn't all that bad unless the number of > individual items being hashed > 32, at which point the SmallVector > overflows and memory is allocated. > > I personally w...

...../include/clang/AST/DeclarationName.h:303:13: note: bool clang::operator<(clang::DeclarationName, clang::DeclarationName) /media/data/dev/llvm/llvm/tools/clang/lib/StaticAnalyzer/Core/../../../include/clang/AST/DeclarationName.h:303:13: note: no known conversion for argument 1 from 'llvm::FoldingSetNodeID' to 'clang::DeclarationName' In file included from /media/data/dev/llvm/llvm/tools/clang/lib/StaticAnalyzer/Core/../../../include/clang/StaticAnalyzer/Core/BugReporter/PathDiagnostic.h:17:0, from /media/data/dev/llvm/llvm/tools/clang/lib/StaticAnalyzer/Core/PathDiagnost...

...ib/System' > make[1]: Entering directory > `/home/czhao/ResearchTools/LLVM/2.3/obj2.3/lib/Support' > llvm[1]: Compiling APInt.cpp for Release build > /home/czhao/ResearchTools/LLVM/2.3/llvm-2.3/lib/Support/APInt.cpp: In > member function 'void llvm::APInt::Profile(llvm::FoldingSetNodeID&) const': > /home/czhao/ResearchTools/LLVM/2.3/llvm-2.3/lib/Support/APInt.cpp:170: > error: call of overloaded 'AddInteger(const uint32_t&)' is ambiguous > /home/czhao/ResearchTools/LLVM/2.3/llvm-2.3/include/llvm/ADT/FoldingSet.h:216: > note: candidates are: void l...

...g/AST/DeclarationName.h:303:13: > note: bool clang::operator<(clang::DeclarationName, clang::DeclarationName) > /media/data/dev/llvm/llvm/tools/clang/lib/StaticAnalyzer/Core/../../../include/clang/AST/DeclarationName.h:303:13: > note: no known conversion for argument 1 from 'llvm::FoldingSetNodeID' to > 'clang::DeclarationName' > In file included from > /media/data/dev/llvm/llvm/tools/clang/lib/StaticAnalyzer/Core/../../../include/clang/StaticAnalyzer/Core/BugReporter/PathDiagnostic.h:17:0, > from > /media/data/dev/llvm/llvm/tools/clang/lib/Static...