search for: findbucket

...only a relatively minor impact (a 10% drop in time spent in LLVM). The instruction cound for `findAnalysisPass` is gone, but the things like `AddInteger` are still called millions of times. Given the number of IR instructions (at most 65K since a 65K IR file), the millions of calls to the Add, and FindBucket functions seems wrong. -- edA-qa mort-ora-y http://mortoray.com/ Creator of the Leaf language http://leaflang.org/ Streaming algorithms, AI, and design on Twitch https://www.twitch.tv/mortoray Twitter edaqa

On 05/05/18 17:58, Andres Freund wrote: > You're building LLVM with assertions enabled > (-DLLVM_ENABLE_ASSERTIONS=ON). > Some of those are fairly expensive... > Is there another way to get LLVM to check the correctness of my IR without the assertions? That's what I'm assuming I need the flag for (it's been a long time since I experimented with it) If there is no way

Hi, On 2018-05-06 00:19:42 +0200, edA-qa mort-ora-y wrote: > On 05/05/18 17:58, Andres Freund wrote: > > You're building LLVM with assertions enabled > > (-DLLVM_ENABLE_ASSERTIONS=ON). > > Some of those are fairly expensive... > > > > Is there another way to get LLVM to check the correctness of my IR > without the assertions? That's what I'm

...less costly that the current approach to merging. The 35sec you’re > seeing > > for merging should go down to about 15sec. I don't do much computing of ghashes as we already preprocess all .obj files from msvc to add a .debug$H to them. The whole 35 seconds is spent in just densehash findbucket function. The rest of the time is mostly pagefaults (I guess to load in obj data and to grow the final pdb?). > The patch doesn’t parallelize > > (yet) the Type merging itself, but we have an alternate > multithread-suitable > > implementation of DenseHash which already supports...

Leonardo, to answer to your questions, yes to all of them  You can take a look at this prototype/proposal: https://reviews.llvm.org/D55585 Overall, computing ghashes in parallel at link-time and merging Types with them is less costly that the current approach to merging. The 35sec you’re seeing for merging should go down to about 15sec. The patch doesn’t parallelize (yet) the Type merging

...rent approach to merging. The 35sec > > you’re seeing > > > > for merging should go down to about 15sec. > > I don't do much computing of ghashes as we already preprocess all .obj files from msvc to add a .debug$H to them. The whole 35 seconds is spent in just densehash findbucket function. The rest of the time is mostly pagefaults (I guess to load in obj data and to grow the final pdb?). > > > The patch doesn’t parallelize > > > > (yet) the Type merging itself, but we have an alternate > > multithread-suitable > > > > implementation o...

...The 35sec > > > you’re seeing > > > > > > for merging should go down to about 15sec. > > > > I don't do much computing of ghashes as we already preprocess all .obj files from msvc to add a .debug$H to them. The whole 35 seconds is spent in just densehash findbucket function. The rest of the time is mostly pagefaults (I guess to load in obj data and to grow the final pdb?). > > > > > The patch doesn’t parallelize > > > > > > (yet) the Type merging itself, but we have an alternate > > > multithread-suitable > > &...

...eing >> > > > >> > > > for merging should go down to about 15sec. >> > > >> > > I don't do much computing of ghashes as we already preprocess all .obj files from msvc to add a .debug$H to them. The whole 35 seconds is spent in just densehash findbucket function. The rest of the time is mostly pagefaults (I guess to load in obj data and to grow the final pdb?). >> > > >> > > > The patch doesn’t parallelize >> > > > >> > > > (yet) the Type merging itself, but we have an alternate >> &gt...

...gt; > > > >> > > > for merging should go down to about 15sec. > >> > > > >> > > I don't do much computing of ghashes as we already preprocess all .obj files from msvc to add a .debug$H to them. The whole 35 seconds is spent in just densehash findbucket function. The rest of the time is mostly pagefaults (I guess to load in obj data and to grow the final pdb?). > >> > > > >> > > > The patch doesn’t parallelize > >> > > > > >> > > > (yet) the Type merging itself, but we have an al...

...eing >> > > > >> > > > for merging should go down to about 15sec. >> > > >> > > I don't do much computing of ghashes as we already preprocess all .obj files from msvc to add a .debug$H to them. The whole 35 seconds is spent in just densehash findbucket function. The rest of the time is mostly pagefaults (I guess to load in obj data and to grow the final pdb?). >> > > >> > > > The patch doesn’t parallelize >> > > > >> > > > (yet) the Type merging itself, but we have an alternate >> &gt...

...gt; > >> > > > for merging should go down to about 15sec. > > >> > > > > >> > > I don't do much computing of ghashes as we already preprocess all .obj files from msvc to add a .debug$H to them. The whole 35 seconds is spent in just densehash findbucket function. The rest of the time is mostly pagefaults (I guess to load in obj data and to grow the final pdb?). > > >> > > > > >> > > > The patch doesn’t parallelize > > >> > > > > > >> > > > (yet) the Type merging itsel...

...t; for merging should go down to about 15sec. > > > > >> > > > > > > >> > > I don't do much computing of ghashes as we already preprocess > all .obj files from msvc to add a .debug$H to them. The whole 35 seconds is > spent in just densehash findbucket function. The rest of the time is mostly > pagefaults (I guess to load in obj data and to grow the final pdb?). > > > > >> > > > > > > >> > > > The patch doesn’t parallelize > > > > >> > > > > > > > >&gt...

...gt;> > > > for merging should go down to about 15sec. > > > >> > > > > > >> > > I don't do much computing of ghashes as we already preprocess all .obj files from msvc to add a .debug$H to them. The whole 35 seconds is spent in just densehash findbucket function. The rest of the time is mostly pagefaults (I guess to load in obj data and to grow the final pdb?). > > > >> > > > > > >> > > > The patch doesn’t parallelize > > > >> > > > > > > >> > > > (yet) th...