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

[Jakob Stoklund Olesen]

On Aug 20, 2012, at 8:19 PM, Sean Silva <silvas at purdue.edu> wrote:

> Would SmallDenseMap be more efficient here since SmallPtrSet does a
> linear scan?

When the set size is bounded, algorithmic complexity becomes meaningless. It's all about the constant factors. With good instruction selection, the linear search loop in SmallPtrSet can start a new iteration each clock cycle. It will probably have started its last iteration before SmallDenseMap has even computed the hash.

The linear search can also start loading table entries before the value you are looking for has been computed. The hash table must wait for the value so it can compute the hash before it can issue the first load.

But don't believe what people tell you. Measure it yourself. They're probably wrong.

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

I agree with Ben that this seems excessive.

> More generally, in what situations is a SmallPtrSet going to be
> preferable to a SmallDenseMap?

I would say always. The performance difference is probably small, but the code size difference isn't.

/jakob