similar to: [LLVMdev] Puzzles on DenseMap

I haven't tested it, but it looks to me like llvm-profdata merge (well, InstrProfWriter specifically) would not have deterministic output. Certainly the textual output iterates over FunctionData which is a StringMap of SmallDenseMaps, neither of which has deterministic iteration. The binary writing looks like it'd have similar issues - looping through these unordered maps & writing

On Thu, Jun 29, 2017 at 7:03 PM Xinliang David Li <davidxl at google.com> wrote: > On Thu, Jun 29, 2017 at 6:27 PM, David Blaikie <dblaikie at gmail.com> wrote: > >> I haven't tested it, but it looks to me like llvm-profdata merge (well, >> InstrProfWriter specifically) would not have deterministic output. >> >> Certainly the textual output iterates

On Thu, Jun 29, 2017 at 7:26 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Thu, Jun 29, 2017 at 7:03 PM Xinliang David Li <davidxl at google.com> > wrote: > >> On Thu, Jun 29, 2017 at 6:27 PM, David Blaikie <dblaikie at gmail.com> >> wrote: >> >>> I haven't tested it, but it looks to me like llvm-profdata merge (well,

On Mon, Nov 16, 2020 at 6:14 PM Sean Silva <chisophugis at gmail.com> wrote: > > > On Mon, Nov 16, 2020 at 4:48 PM Mehdi AMINI <joker.eph at gmail.com> wrote: > >> >> >> On Mon, Nov 16, 2020 at 4:10 PM David Blaikie <dblaikie at gmail.com> wrote: >> >>> On Mon, Nov 16, 2020 at 2:44 PM Mehdi AMINI <joker.eph at gmail.com> wrote:

Hi Duncan, I came across something like the following recently which I guess might be related to your recent work. Any ideas? $ clang++-tot -cc1 crash_on_invalid.cpp -g -emit-obj -fexceptions -fcxx-exceptions crash_on_invalid.cpp:13:1: error: C++ requires a type specifier for all declarations x; ^ 1 error generated. *** Error in `clang++-tot': corrupted double-linked list: 0x000000000754f340

On Mon, Nov 16, 2020 at 4:10 PM David Blaikie <dblaikie at gmail.com> wrote: > On Mon, Nov 16, 2020 at 2:44 PM Mehdi AMINI <joker.eph at gmail.com> wrote: > > > > > > > > On Mon, Nov 16, 2020 at 2:12 PM David Blaikie <dblaikie at gmail.com> > wrote: > >> > >> On Mon, Nov 16, 2020 at 1:55 PM Mehdi AMINI <joker.eph at

On Mon, Nov 16, 2020 at 4:48 PM Mehdi AMINI <joker.eph at gmail.com> wrote: > > > On Mon, Nov 16, 2020 at 4:10 PM David Blaikie <dblaikie at gmail.com> wrote: > >> On Mon, Nov 16, 2020 at 2:44 PM Mehdi AMINI <joker.eph at gmail.com> wrote: >> > >> > >> > >> > On Mon, Nov 16, 2020 at 2:12 PM David Blaikie <dblaikie at

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 *

> Assuming the default value is not a valid entry in your map (for instance, > if you're using pointers), you can do: > > Foo& entry = DenseMap[Key] > if (entry == DefaultValue) > entry = constructNewValue(); The problem here is that the DefaultValue is undefined. However, Chris suggested that the default value, ValueT(), is not undefined but simply zero. However, on

On Fri, Jun 6, 2008 at 12:27 AM, Matthijs Kooijman <matthijs at stdin.nl> wrote: >> Assuming the default value is not a valid entry in your map (for instance, >> if you're using pointers), you can do: >> >> Foo& entry = DenseMap[Key] >> if (entry == DefaultValue) >> entry = constructNewValue(); > The problem here is that the DefaultValue

In the midst of making TableGen Inits unique, I've run into some very odd DenseMap behavior. I converted the TernOpInit to use a factory method that uses a DenseMap to unique objects. I have defined a DenseMapInfo for std::string that uses HashString from StringExtras.h. const TernOpInit *TernOpInit::get(TernaryOp opc, const Init *lhs, const Init *mhs,

> On Mar 15, 2016, at 4:56 PM, Philip Reames via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Er, LoadValue's been around for a while (6 months). How far back are you testing? I'd strongly suggest switching to something more recent. Some of us have to support internal release branches for non-trivial amounts of time. —Owen -------------- next part -------------- An

From: José Fonseca <jfonseca at vmware.com> When the hash function uses object pointers all free entries eventually become tombstones as they are used at least once, regardless of the size. DenseMap cannot function with zero empty keys, so it double size to get get ridof the tombstones. However DenseMap never shrinks automatically unless it is cleared, so the net result is that certain

Assuming the default value is not a valid entry in your map (for instance, if you're using pointers), you can do: Foo& entry = DenseMap[Key] if (entry == DefaultValue) entry = constructNewValue(); ... // Use entry --Owen On Jun 5, 2008, at 7:49 AM, Matthijs Kooijman wrote: > Hi All, > > I've been fiddling around with a DenseMap to store cached copies of > some

Hi, I have a question about llvm/ADT/DenseMap.h and llvm/IR/ValueMap.h: When you have a: MapType M; is it safe to do: M[NewKey] = M[OldKey]; or do you need to do it in two steps: auto tmp = M[OldKey]; // ensure the reference to M[OldKey] is copied, before reassigning. M[NewKey] = tmp; // might reallocate aka, will a possible allocation for M[NewKey] invalidate the

Oliver Horst wrote: > Dear All, > > while willing to assist developers to adhere strictly to coding guidelines, I > wrote the attached program called "alias-detector". The program's intent is to > utilize the BasicAliasAnalysis to get a list of aliases for each pointer in a > certain program code. First it initializes clang as frontend, executes the >

+template <bool, typename True, typename False> +struct If { typedef True Result; }; + +template <typename True, typename False> +struct If<false, True, False> { typedef False Result; }; These should probably go into include/llvm/Support/type_traits.h. In C++0x, this is named "conditional" (section 20.6.7), so I think you should use the same name, despite the standard

Hi All, I've been fiddling around with a DenseMap to store cached copies of some result. In short, I'm doing the following: It = Map.find(Key) if (It != Map.end() && It->second != Unknown) Return It->second; // do_stuff return Map[Key] = Result; However, I this requires two lookups in the hash table, which is not so nice. Currently, there is no way to write this down so

+ // Otherwise this is a copy constructor for const_iterator. Do you mean "for iterator"? Otherwise, looks good to me. If you can commit this, please do. Otherwise, someone else should as I'm not going to be around tomorrow. On Wed, Nov 4, 2009 at 12:27 AM, Victor Zverovich <victor.zverovich at googlemail.com> wrote: > Hi Jeffrey, > You are right that the generated

Dear all, The first of the proposed patches (DenseMapIterator.patch) forbids implicit conversion of DenseMap::const_iterator to DenseMap::iterator which was possible because DenseMapIterator inherited (publicly) from DenseMapConstIterator. Conversion the other way around is now allowed as one may expect. The template DenseMapConstIterator is removed and the template parameter IsConst which