search for: summarybuild

...the in memory hashtable and the > hashtable is then dumped into the disk. The entry order of the hashtable > only depends on the string hashes and in case of conflicts, the function > content hash. > Ah, so you mean the loop in InstrProfRecordWriterTrait::EmitData that inserts into the SummaryBuilder - the SummaryBuilder itself doesn't depend on the order of 'addRecord' calls - ah, I see, addRecord -> addEntryCount -> addCount -> CountFrequencies, a std::map (thus, ordered by value, independent of call order of addRecord). But inside that loop, it also starts writing dir...

...e >> hashtable is then dumped into the disk. The entry order of the hashtable >> only depends on the string hashes and in case of conflicts, the function >> content hash. >> > > Ah, so you mean the loop in InstrProfRecordWriterTrait::EmitData that > inserts into the SummaryBuilder - the SummaryBuilder itself doesn't depend > on the order of 'addRecord' calls - ah, I see, addRecord -> addEntryCount > -> addCount -> CountFrequencies, a std::map (thus, ordered by value, > independent of call order of addRecord). > > But inside that loop, it...

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