search for: smalldensemaps

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 output (eg: InstrProfRecordWriterTrait::EmitData loops through the data in the same SmallDenseMap and writes content in that order so far a...

...ie 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 over FunctionData which is a >> StringMap of SmallDenseMaps, neither of which has deterministic iteration >> > > Does the iteration order of these maps depend on the order of hashes (of > strings for StringMap)? > Right - that's my understanding. (Some folks have started adding interesting things to LLVM to try to help weed out these...

...e: >> >>> 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 >>> >> >> Does the iteration order of these maps depend on the order of hashes (of >> strings for StringMap)? >> > > Right - that's my understanding. > > (Some folks have started adding interesting things...

I wrote some program using DensMap like this: =============================== SmallDenseMap<Value*, StringRef, 4> OpResult; Value *VP = GEP->getPointerOperand(); OpResult[VP] = parseVariable(VP); for(User::op_iterator sId = GEP->idx_begin(), eId = GEP->idx_end(); sId != eId; ++sId) { Value *VI = *sId; if(dyn_cast<ConstantInt>(*sId)) OpResult[VI] =

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: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

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

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 *

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 gmail.com> wrote: > > On Mon, Nov 16, 2020 at 12:55 PM David Blaikie <dblaikie at gmail.com> > wrote: > >> > >> I will say I'm not a huge fan of adding even more names for things in > >> this fairly