search for: mapvector

...d an unsigned index into the Vector: /// The values are kept in a std::vector and the /// mapping is done with DenseMap from Keys to indexes in that vector. After an element is erased from the Vector all indices greater than the removed index are one too large. That's probably the reason why Mapvector did not have erase before. See http://llvm.org/docs/ProgrammersManual.html#llvm-adt-mapvector-h ...and it doesn't support removing elements. To correct this erase needs to decrement all vector indices in the Map which are larger than the removed index. Note that pop_back() does not have t...

...:29, David Blaikie <dblaikie at gmail.com> wrote: >>>>> >>>>> Sounds pretty clearly buggy, and against the original design of the >>>>> ADT (as pointed out by the documentation quotation). When was erase >>>>> functionality added to MapVector? Can/should it be removed (and the >>>>> use case changed to use some other container) >>>>> >>>>> Making erase linear time sounds... not ideal, but possibly its >>>>> sufficient for some/current use cases. Or we could consider other >...

...t;>> On 2014-Jul-15, at 08:29, David Blaikie <dblaikie at gmail.com> wrote: >>> >>> Sounds pretty clearly buggy, and against the original design of the >>> ADT (as pointed out by the documentation quotation). When was erase >>> functionality added to MapVector? Can/should it be removed (and the >>> use case changed to use some other container) >>> >>> Making erase linear time sounds... not ideal, but possibly its >>> sufficient for some/current use cases. Or we could consider other >>> solutions to the use ca...

> On 2014-Jul-15, at 08:29, David Blaikie <dblaikie at gmail.com> wrote: > > Sounds pretty clearly buggy, and against the original design of the > ADT (as pointed out by the documentation quotation). When was erase > functionality added to MapVector? Can/should it be removed (and the > use case changed to use some other container) > > Making erase linear time sounds... not ideal, but possibly its > sufficient for some/current use cases. Or we could consider other > solutions to the use cases. Heh -- it's already linear. I...

...w/o tests). For now, I'll fix it, and then David (or someone else) can migrate the code to `remove_if()`. FWIW, when it's fixed, it doesn't have to be "unsupported" -- it's just *slow*. -------------- next part -------------- A non-text attachment was scrubbed... Name: mapvector.patch Type: application/octet-stream Size: 1999 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140715/00ee4949/attachment.obj>

...m 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/attachment.html>

...fixes I can think of: 1. have some special logic to remember the offsets for the tombstone and empty i64 constants. This can easily be tracked using two "Optional<int>" fields. 2. change ConstantPool to be use a std::map instead of a llvm::DenseMap as the map in the MapVector. An aside: the same function has this check "((I->Offset + (int64_t(1)<<31)) >> 32)" -- won't this cause a signed overflow (and hence UB) if I->Offset is negative? -- Sanjoy

.../APInt.h" #include "llvm/ADT/ArrayRef.h" #include "llvm/ADT/BitVector.h" #include "llvm/ADT/CachedHashString.h" #include "llvm/ADT/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....

...s there a reason that wouldn't be the case for llvm-profdata? Or have I misunderstood how the output is determined? Ensuring deterministic output may be expensive in terms of memory usage, though perhaps not prohibitive. The usual approach is to use some of LLVM's deterministic maps (like MapVector), though they're not exactly tuned for memory usage. An alternative might be to take the data in each SmallDenseMap and sort it by the hash as a key - it's unique after all, and doing each map separately won't do crazy bad things to memory usage (a small constant overhead). Handling th...

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

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,

...need deterministic behavior. For > debug output, we can relax that requirement. > > >> Ensuring deterministic output may be expensive in terms of memory usage, >> though perhaps not prohibitive. The usual approach is to use some of LLVM's >> deterministic maps (like MapVector), though they're not exactly tuned for >> memory usage. An alternative might be to take the data in each >> SmallDenseMap and sort it by the hash as a key - it's unique after all, and >> doing each map separately won't do crazy bad things to memory usage (a >> sm...

...; >> #include "llvm/ADT/BitVector.h" >> #include "llvm/ADT/CachedHashString.h" >> #include "llvm/ADT/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...

...vior. For >> debug output, we can relax that requirement. >> >> >>> Ensuring deterministic output may be expensive in terms of memory usage, >>> though perhaps not prohibitive. The usual approach is to use some of LLVM's >>> deterministic maps (like MapVector), though they're not exactly tuned for >>> memory usage. An alternative might be to take the data in each >>> SmallDenseMap and sort it by the hash as a key - it's unique after all, and >>> doing each map separately won't do crazy bad things to memory usage (a...

...ctor.h" >>>> #include "llvm/ADT/CachedHashString.h" >>>> #include "llvm/ADT/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....

...llvm/ADT/ArrayRef.h" > #include "llvm/ADT/BitVector.h" > #include "llvm/ADT/CachedHashString.h" > #include "llvm/ADT/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" > #...

Hi Rafael, On 07/31/2017 04:20 PM, Rafael Avila de Espindola via llvm-dev wrote: > However, do we need to start with instrumentation? The original paper > uses sampling with good results and current intel cpus can record every > branch in a program. > > I would propose starting with just an lld patch that reads the call > graph from a file. The format would be very similar to

..."llvm/ADT/BitVector.h" >>> #include "llvm/ADT/CachedHashString.h" >>> #include "llvm/ADT/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" >>>...

...ctor.h" >>>> #include "llvm/ADT/CachedHashString.h" >>>> #include "llvm/ADT/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....

...> Rafael -------------- next part -------------- diff --git a/ELF/Config.h b/ELF/Config.h index 45c9565..6928583 100644 --- a/ELF/Config.h +++ b/ELF/Config.h @@ -10,6 +10,7 @@ #ifndef LLD_ELF_CONFIG_H #define LLD_ELF_CONFIG_H +#include "llvm/ADT/DenseMap.h" #include "llvm/ADT/MapVector.h" #include "llvm/ADT/StringRef.h" #include "llvm/ADT/StringSet.h" @@ -108,6 +109,8 @@ struct Configuration { std::vector<SymbolVersion> VersionScriptLocals; std::vector<uint8_t> BuildIdVector; llvm::MapVector<Symbol *, RenamedSymbol> RenamedSym...