Displaying 3 results from an estimated 3 matches for "addrecord".
Did you mean:
addrecops
2017 Jun 30
2
llvm-profdata determinism
...try 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 directly to 'Out' based on the
order of the SmallDenseMap, doesn't it?...
2017 Jun 30
0
llvm-profdata determinism
...> 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 directly to 'Out' based on
> the order of the SmallDe...
2017 Jun 30
2
llvm-profdata determinism
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