[llvm-commits] [llvm] r162222 - /llvm/trunk/lib/Target/ARM/ARMISelLowering.cpp

[Benjamin Kramer]

On 21.08.2012, at 05:19, Sean Silva <silvas at purdue.edu> wrote:

> Would SmallDenseMap be more efficient here since SmallPtrSet does a
> linear scan? There's also a SmallPtrSet of size 64 in the DAG combiner
> that I think would significantly benefit from becoming a SmallDenseMap
> (64 means that when it is pretty large but still in its small storage
> it does a linear scan over up to 8 cache lines).
> 
> More generally, in what situations is a SmallPtrSet going to be
> preferable to a SmallDenseMap?

For only 8 entries the entire linearly scanned buffer fits into 8*8=64 bytes on
x86_64, which should be really fast even with a linear scan, maybe even faster
than doing a hash lookup.

For 64*8 bytes the situation is different, that SmallPtrSet should be either
shrunk or replaced with a SmallDenseMap (which carries its own overhead because
it stores keys and values).

DenseSet is implemented as a DenseMap<foo, char>, if you stick a pointer in
there every entry is sizeof(void *) + 1 + padding = 2 * sizeof(void*), a
significant memory overhead.

Of course, if malloc thrashing in turn dwarves this overhead, SmallDenseMap
would be a good idea. Real numbers would be nice but I guess it's hard to
find a test case where llvm spends a lot of time in badly configured
SmallPtrSets.

- Ben