[PATCH] D35148: Use DenseMap instead std::map for GVSummaryMapTy.

[Mehdi AMINI via Phabricator via llvm-commits]

mehdi_amini added a comment.

In https://reviews.llvm.org/D35148#803251, @tejohnson wrote:

> In https://reviews.llvm.org/D35148#803193, @mehdi_amini wrote:
>
> > When we used an std::map originally it was because we needed the ordering. Have you checked that we don't iterate on any instance of this map?
>
>
> From http://llvm.org/docs/ProgrammersManual.html#llvm-adt-densemap-h it doesn't appear that iteration order is an issue for DenseMap.


As long as keys aren't pointers...
(But just as every hash_map right?)

> StringMap on the other hand does not have a deterministic iteration ordering, and I recall using a std::map somewhere instead of a StringMap for that reason.

Really? I'm pretty sure the order is deterministic, but just like any hash_map (including DenseMap): the order of insertion and the hash function are determining the resulting order.

> Note the index itself still uses a std::map, for other reasons (documented at the declaration). We also still use a std::map where we write out the individual index files for the backends in the distributed backend case. In any case from what I can tell, we typically query this map, rather than iterate. The only place I see an iteration is when we are computing imports for a module, so I suppose that could affect the debug output ordering, but does that matter (if iteration order is even non-deterministic for DenseMap, and from what I can tell from the LLVM doc linked above it isn't).

OK!


https://reviews.llvm.org/D35148