search for: setvector

I have no idea why this code compiled correctly with gcc... m. Index: include/llvm/ADT/SetVector.h =================================================================== RCS file: /var/cvs/llvm/llvm/include/llvm/ADT/SetVector.h,v retrieving revision 1.8 diff -u -r1.8 SetVector.h --- include/llvm/ADT/SetVector.h 11 Sep 2004 20:38:25 -0000 1.8 +++ include/llvm/ADT/SetVector.h 13...

Hello, The CodeExtractor contains a std::set<BasicBlock*> to keep track of the blocks to extract. Iterators on this set are not deterministic, and so the functions that are generated are not (the order of the inputs/outputs can change). The attached patch uses a SetVector instead. Ok to apply ? Thanks, Julien -- Julien Lerouge PGP Key Id: 0xB1964A62 PGP Fingerprint: 392D 4BAD DB8B CE7F 4E5F FA3C 62DB 4AA7 B196 4A62 PGP Public Key from: keyserver.pgp.com -------------- next part -------------- Index: lib/Transforms/Utils/CodeExtractor.cpp ========================...

...contains a std::set<BasicBlock*> to keep track > >of the > >blocks to extract. Iterators on this set are not deterministic, and so > >the functions that are generated are not (the order of the > >inputs/outputs can change). > > > >The attached patch uses a SetVector instead. Ok to apply ? > Nice catch, please apply, > -Chris Thanks for the quick review. There is actually more, is it ok to apply this one as well (avoid std:vector<Value*> being sorted) ? Thanks, Julien -- Julien Lerouge PGP Key Id: 0xB1964A62 PGP Fingerprint: 392D 4BAD DB8B CE...

...> The CodeExtractor contains a std::set<BasicBlock*> to keep track of > the > blocks to extract. Iterators on this set are not deterministic, and so > the functions that are generated are not (the order of the > inputs/outputs can change). > > The attached patch uses a SetVector instead. Ok to apply ? Nice catch, please apply, -Chris > > Thanks, > Julien > > > -- > Julien Lerouge > PGP Key Id: 0xB1964A62 > PGP Fingerprint: 392D 4BAD DB8B CE7F 4E5F FA3C 62DB 4AA7 B196 4A62 > PGP Public Key from: keyserver.pgp.com > <codeextractor.diff...

tl;dr: I think we have too many different set classes. They have incompatible APIs and surprising behavior. I think we can reduce their number substantially. Dear all, The following is a subset of the set classes we have in ADT: * DenseSet * SmallDenseSet (https://reviews.llvm.org/D25628) * SetVector * SmallSetVector * SmallSet * SmallPtrSet * StringSet * FoldingSet * ContextualFoldingSet * FoldingSetVector Every one of these classes has quirks. Here are some particularly bad ones: * SmallSet falls back to std::set<T> when it runs out of inline storage (which itself is pretty...

.... The iteration order of ExitBlocks is > important. In llvm, generating unique sets is a pain because values are not > numbered and iteration order needs to be reproducible. We would need to keep > a SmallPtrSet for membership checking while populating the result vector. What about use the SetVector[1] as container? As its comment say: This adapter class provides a way to keep a set of things that also has the property of a deterministic iteration order. The order of iteration is the order of insertion. best regards ether [1]http://www.llvm.org/doxygen/classllvm_1_1SetVector.html > > -...

Is it kosher to include vim mode line comments inside of LLVM source files? I would like to do this inside of the MicroBlaze backend to ensure that tabs are expanded into exactly two spaces. I see that right now the following files have these vim mode line comments: include/llvm/ADT/SetVector.h lib/Archive/ArchiveInternals.h lib/Linker/LinkModules.cpp lib/Transforms/IPO/DeadTypeElimination.cpp lib/VMCore/Function.cpp Since this does not seem to be a wide spread practice I thought I would ask before I made the changes. -- Wesley Peck University of Kansas SLDG Laboratory

On Apr 23, 2012, at 10:31 PM, Andrew Trick <atrick at apple.com> wrote: > > On Apr 19, 2012, at 10:43 PM, xiaoming gu <xiaoming.gu at gmail.com> wrote: > >> Hi, all. I'm using void LoopBase::getExitBlocks (SmallVectorImpl< BlockT * > &ExitBlocks) const to get all >> exit blocks for a loop. The problem I find with this API is that it returns

Background: I am still working on vectorizing (widening) a whole instruction tree (from the loads to the stores). I have all scalar loads in a SetVector and have created widened version of them (new instructions). What would be very useful to have is the possibility to get to the vector load instruction from the scalar load in constant time. I was thinking to somehow add the vector load instruction (pointer) to the scalar version as metadata. W...

...I am at this time not proposing anything - a fix is definitely possible, but I wonder what people think about it before I even consider this a bug. This looks like a bug. The edge order could even affect some heuristics and influence codegen. I don't have a better idea than using SetVector/MapVector for Value* keys. For SUnits we could just key on NodeNum. Go ahead and file a bug and/or submit a patch. Thanks! -Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121017/6b30a33c/attachmen...

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 (revision 39772) +++ b/lib/Transforms/Scalar/Fa...

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

...iced that llc hung in an STL iterator loop given trivial bytecode input (essentially a single function to add a couple of integers). The bytecode compiled fine from llvm assembly via llvm-as. The hang was in one of the STL destroy() loops; basically _first was ok (originated inside the bowels of a SetVector (Value*)), but _last was an at best undefined pointer (something like 0x013), so the loop would just chug along forever, and crash at some point I presume because it doesn't sound healthy to walk through the entire free store. Has anyone seen this or should I try to find the cause? Best regar...

.../DenseSet.h" #include "llvm/ADT/IndexedMap.h" #include "llvm/ADT/IntEqClasses.h" #include "llvm/ADT/MapVector.h" #include "llvm/ADT/Optional.h" #include "llvm/ADT/PointerUnion.h" #include "llvm/ADT/STLExtras.h" #include "llvm/ADT/SetVector.h" #include "llvm/ADT/SmallPtrSet.h" #include "llvm/ADT/SmallSet.h" #include "llvm/ADT/SmallVector.h" #include "llvm/ADT/SparseBitVector.h" #include "llvm/ADT/Statistic.h" #include "llvm/ADT/StringExtras.h" #include "llvm/ADT/Str...

...gt; > I am at this time not proposing anything – a fix is definitely possible, but I wonder what people think about it before I even consider this a bug. This looks like a bug. The edge order could even affect some heuristics and influence codegen. I don't have a better idea than using SetVector/MapVector for Value* keys. For SUnits we could just key on NodeNum. Go ahead and file a bug and/or submit a patch. Thanks! -Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121016/48a22da7/attachment.htm...

.... I get the following error (with path prefixes shortened for convenience) when compiling llvm-gcc: > In file included from [...]/llvm/include/llvm/ADT/SmallPtrSet.h:20, > from [...]/llvm/include/llvm/ADT/SmallSet.h:18, > from [...]/llvm/include/llvm/ADT/SetVector.h:23, > from ../../llvm-gcc-src/gcc/llvm-internal.h:38, > from ../../llvm-gcc-src/gcc/llvm-backend.cpp:23: > [...]/llvm/include/llvm/Support/DataTypes.h:38:3: error: #error "Must #define __STDC_LIMIT_MACROS before #including Support/DataTypes.h"...

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

Andy, This is less of a question but rather a status quo verification. We currently have certain indeterminism in MI scheduler DAG construction - it is introduces by the use of std::map/std::set during edge traversal. Result - a random variation in SUnit edge order (which will remain fixed thereafter). Logically, it is the same DAG, but topologically it is a slightly different one,

...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. If you need to access in insertion order then go with SmallVector + slow search. If you need sorted order then go with stl set. If you don't care, pick which one makes the most sense for your constraints: SmallVector uses...

Some time ago we reported a compile-time performance regression in the LiveIntervals analysis pass (see http://llvm.org/bugs/show_bug.cgi?id=18580). We detected it at first after migrating from LLVM 3.1 to 3.3, but the problem persists also in 3.5. This regression is especially critical when compiling long functions. In one of our benchmarks compile time goes from 200s (in 3.1) up to 1500s (in