This is an archive of the discontinued LLVM Phabricator instance.

[LVI] Use DenseMap::find_as in LazyValueInfo.
ClosedPublic

Authored by jlebar on Jul 1 2016, 9:15 PM.

Details

Summary

This lets us avoid creating and destroying a CallbackVH every time we
check the cache.

This is good for a 2% e2e speedup when compiling one of the large Eigen
tests at -O3.

FTR, I tried making the ValueCache hashtable one-level -- i.e., mapping
a pair (Value*, BasicBlock*) to a lattice value, and that didn't seem to
provide any additional improvement. Saving a word in LVILatticeVal by
merging the Tag and Val fields also didn't yield a speedup.

Diff Detail

Repository
rL LLVM

Event Timeline

jlebar updated this revision to Diff 62599.Jul 1 2016, 9:15 PM
jlebar retitled this revision from to [LVI] Use DenseMap::find_as in LazyValueInfo..
jlebar updated this object.
jlebar added a reviewer: reames.
jlebar added a subscriber: llvm-commits.
jlebar added a reviewer: rnk.Jul 26 2016, 12:57 PM
rnk added inline comments.Jul 26 2016, 1:14 PM
lib/Analysis/LazyValueInfo.cpp
417–418 ↗(On Diff #62599)

This type is probably too large to use with DenseMap. I would expect that the keys would end up spaced out in memory, making lookup more expensive. Maybe try using a separate allocation for the value like this:

struct ValueCacheEntryTy {
  LVIValueHandle Handle;
  SmallDenseMap<AssertingVH<BasicBlock>, LVILatticeVal, 4> BBs;
};
DenseMap<Value *, std::unique_ptr<ValueCacheEntryTy>> ValueCache;

On the other hand, maybe your 2% win is from avoiding separate allocation overhead. This is probably worth a quick benchmark, though.

jlebar updated this revision to Diff 65799.Jul 27 2016, 1:48 PM

Use smaller values in the DenseMap.

Doesn't make a difference in my profile, but I agree that it's cleaner this way.

rnk accepted this revision.Jul 27 2016, 3:31 PM
rnk edited edge metadata.

lgtm

IMO long term DenseMap should abstract this away from the user, so that large keys and values are stored in separate allocations. That's another story though.

This revision is now accepted and ready to land.Jul 27 2016, 3:31 PM
This revision was automatically updated to reflect the committed changes.