similar to: RFC: Reducing the number of set classes in ADT

UniqueVector is an stl map coupled with an stl vector[1], which seems very undesirable for you. As far as SmallVector + slow search, I believe that is precisely what the implementation of SmallSet does until it has to grow, after which it uses an stl set[2]. If you're always staying within your small number, SmallSetVector would be wasteful as the SmallSet would itself also have a SmallVector.

Hi, Thanks a lot for the help! It seems that the SmallSetVector is the ADT I need (interface-wise). Is more efficient than llvm::UniqueVector? In my use case I have to insert a new element in the structure only if the element is unique. I hardly expect more than 32 elements. Do you think I gain a lot if I use the SmallSetVector instead of using SmallVector + slow searching on every

Changing a header file somewhere and having to spend 10 minutes waiting for a build leads to a lot of wasted developer time. The real culprit here is tablegen. Can we split support and ADT into two - the parts that tablegen depends on and the parts that it doesn't? >From what I can gather, Tablegen currently depends on these headers and all of their transitive dependencies. #include

Something that might interest you is the SetVector, which as its name implies is both a set and a vector paired together. You get the advantage of doing set-like operations (search) on the set and vector-like operations (iteration, random access) on the vector, but at the cost of paying the price for both data structures when modifying the structure (and double the memory). This seems like it

It would be better, because a debug tablegen is slower than an optimized tablegen, but it's still slow and it doesn't address the problem that tablegen runs *at all* when it doesn't really need to. I think if tablegen wasn't running all the time we could incremental builds down from 15 minutes (and that's on my really powerful machine) to under 5, which seemed like a big

It's that TableGen depends on Support, so if you change one file in support, support gets recompiled into a new static archive, which triggers a rerun of tablegen on all the tablegen inputs, which is extremely slow. On Fri, May 26, 2017 at 5:56 PM Hal Finkel <hfinkel at anl.gov> wrote: > > > On 05/26/2017 07:47 PM, Zachary Turner via llvm-dev wrote: > > Changing a header

I thought we already did write tablegen output to temporary files like X86GenAsmWriter1.inc.tmp first and then diffed them with the real .inc file and conditionally copied. ~Craig On Sat, May 27, 2017 at 11:02 AM, David Blaikie via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Fri, May 26, 2017 at 8:06 PM Zachary Turner via llvm-dev < > llvm-dev at

Thank you for the idea! Could you please explain it? If I’m not mistaken, you advise to insert the unknown insts of an every AS from AliasSetTracker::add(const AliasSetTracker &AST) into a smallptrset and consequently append it to merged alias sets from AliasSetTracker::findAliasSetForUnknownInst. I think that Philip proposed something similar to your approach in

> On May 30, 2017, at 3:49 PM, Pete Cooper via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On May 30, 2017, at 12:05 PM, Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Let me try starting over without mentioning Tablegen :) > Aw, but i had a list of issues, such as: > -

In my experience the buildsystem works fine in combination with tablegen (at least this aspect of it). The real problem here is that tablegen is just slow. Some of the X86 tables take indeed Last time I looked at it tablegen had still room to optimize the way it resolves class hierarchies and the variables within which it did basically one at a time, so it needed to traverse the hierarchies

> On May 30, 2017, at 12:05 PM, Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Let me try starting over without mentioning Tablegen :) Aw, but i had a list of issues, such as: - tablegen doesn’t generate .d files - CMake is set up with far reaching deps on .td files, so changing Options.td rebuilds the backends, and adding an ARM intrinsic rebuilds X86 or vice

From an x86-64 machine, I'm trying to compile llvm and llvm-gcc. I'm using the LLVM 2.5 release, and the associated llvm-gcc tarball. llvm compiles fine; ours is compiled to a Debugging version. llvm-gcc, though, is angry. I get the following error (with path prefixes shortened for convenience) when compiling llvm-gcc: > In file included from

On 08/13/2009 07:35 PM, Matt Elder wrote: > From an x86-64 machine, I'm trying to compile llvm and llvm-gcc. I'm > using the LLVM 2.5 release, and the associated llvm-gcc tarball. llvm > compiles fine; ours is compiled to a Debugging version. llvm-gcc, > though, is angry. I get the following error (with path prefixes > shortened for convenience) when compiling llvm-gcc:

On 01/27/2016 07:53 AM, Daniel Berlin wrote: > > > On Wed, Jan 27, 2016 at 1:27 AM, Roman Gareev <gareevroman at gmail.com > <mailto:gareevroman at gmail.com>> wrote: > > Thank you for the idea! Could you please explain it? > > > Which part are you having trouble with, so i know where to concetrate? > > If I’m not > mistaken, you advise

On Jul 9, 2011, at 11:30 AM, Talin wrote: > I'm using the various LLVM set containers (SmallPtrSet and the like), and something I need to do fairly often is iterate over a set, removing all elements that don't pass a test. Now, doing this on lists is fairly straightforward using the "it = container.erase(it)" idiom so as to keep the iterator valid during the delete. However,

Everyone, The following patch to reverse iterate SmallPtrSet's has now been merged: https://reviews.llvm.org/D26718 This is how LLVM behavior will change due to this patch: - In LLVM builds with *assertions enabled*, SmallPtrSet's would always be reverse iterated by default. This default behavior can be overridden via the flag "-mllvm -reverse-iterate=<true/false>".

fix the following warning: FastDSE.cpp: In member function ‘bool<unnamed>::FDSE::handleEndBlock(llvm::BasicBlock&, llvm::SetVector<llvm::Instruction*, std::vector<llvm::Instruction*, std::allocator<llvm::Instruction*> >, llvm::SmallSet<llvm::Instruction*, 16u> >&)’: FastDSE.cpp:174: warning: unused variable ‘AA’ --- a/lib/Transforms/Scalar/FastDSE.cpp

On Tue, 4 Dec 2007, David Greene wrote: > What are the rules regarding iterator stability for SmallPtrSet? > I'm running into a problem where erasing an element seems > to invalidate iterators that are not pointing at the erased element. Interesting question. > Specifically, the set is in small mode, I advance an iterator to the last > element in the set (not end(), but one

> On 2016-Nov-15, at 15:16, Hal Finkel <hfinkel at anl.gov> wrote: > > ----- Original Message ----- >> From: "Mandeep Singh via llvm-dev Grang" <llvm-dev at lists.llvm.org> >> To: llvm-dev at lists.llvm.org, "mehdi amini" <mehdi.amini at apple.com>, dexonsmith at apple.com, zinob at codeaurora.org >> Sent: Tuesday, November 15, 2016

Everyone, There is non-determinism in LLVM codegen in the following scenarios: 1. Between back-to-back runs of the same LLVM toolchain 2. Between Release vs Release+Asserts toolchains 3. Between Linux vs Windows toolchains The main reasons for the non-determinism in codegen are: 1. Iteration of unordered containers (like SmallPtrSet, DenseMap, etc) where the iteration order is undefined 2.