[llvm-commits] [patch] Add a MapVector class

Rafael EspĂ­ndola rafael.espindola at gmail.com
Tue Sep 18 15:05:55 PDT 2012


>> 2) Store vector<pair<const KeyT, ValueT>> as the vector storage, and make
>> the densemap not even contain the keys.
>
> ...
>
>> #2 is appealing in interesting ways. While slower than a traditional
>> DenseMap, it would have none of the traditional limitations. The DenseMap
>> could actually be DensMap<unsigned, unsigned> where the key is the hash_code
>> converted to an unsigned, and the value is the index. It also provides a
>> natural way to support the pair-based value_type interface points. However,
>> it would have strictly worse locality than your solution or #1.
>
> This is interesting. We can pass a KeyInfoT that has an identity hash
> to avoid hashing twice. I will try this as a plan B.

Looking at pr13868 I found other cases where we had non-deterministic
output because of iteration on the very same objects that caused the
problem I noticed before, so I decided to try #2.

We cannot just use a DenseMap<unsigned, unsigned> or a hash collision
would cause us to conclude that a key was already in the Map.

An important observation is that in cases where we want to use this
class the key is usually a simple object like a pointer. Given that I
propose we just use a DenseMap<KeyT, unsigned> and a
std::vector<std::pair<KeyT, ValueT> > and let users that need a more
compact representation refactor/design something ad-hoc. At least this
class becomes really hard to misuse.

These patches should fix the original problem and pr13868.

Cheers,
Rafael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: clang.patch
Type: application/octet-stream
Size: 1950 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120918/3c83dce7/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm.patch
Type: application/octet-stream
Size: 4482 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120918/3c83dce7/attachment-0001.obj>


More information about the llvm-commits mailing list