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

[Teresa Johnson via llvm-commits]

On Sun, Jul 9, 2017 at 7:35 PM, Mehdi AMINI via Phabricator <
reviews at reviews.llvm.org> wrote:

> 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?)
>

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

According to the end of
http://llvm.org/docs/ProgrammersManual.html#llvm-adt-stringmap-h the
iteration order is non-deterministic.


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


-- 
Teresa Johnson |  Software Engineer |  tejohnson at google.com |  408-460-2413
<(408)%20460-2413>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170710/86996792/attachment.html>