[PATCH] D11651: [LVI] Improve LazyValueInfo compile time performance
Duncan P. N. Exon Smith
dexonsmith at apple.com
Wed Aug 5 14:44:28 PDT 2015
> On 2015-Jul-30, at 08:45, Bruno Cardoso Lopes <bruno.cardoso at gmail.com> wrote:
>
> bruno created this revision.
> bruno added reviewers: resistor, hfinkel, reames.
> bruno added subscribers: llvm-commits, dexonsmith.
>
> Changes in LoopUnroll in the past six months exposed scalability
> issues in LazyValueInfo when used from JumpThreading. One internal test
> that used to take 20s under -O2 now takes 6min.
>
> This patch makes a couple of changes to speed-up LazyValueInfo and
> reduces compile time to 1m20s.
>
> - Change the OverDefinedCache from
> DenseSet<std::pair<AssertingVH<BasicBlock>, Value*>>
> to
> DenseMap<AssertingVH<BasicBlock>, SmallPtrSet<Value *, 4>>
>
> - Use DenseMap instead of std::map for ValueCacheEntryTy. Historically
> there seems to be some resistance regarding the change to DenseMap
> (r147980), but I couldn't find cases of iterator invalidation for
> ValueCacheEntryTy (only for ValueCache, but this one is left unchanged
> - still using std::map).
>
>
> http://reviews.llvm.org/D11651
>
> Files:
> lib/Analysis/LazyValueInfo.cpp
>
> <D11651.31032.patch>
The `OverdefinedCache` changes LGTM, assuming you commit it
separately (this are separable, right? If one of them causes an
invalidation bug, committing separately will make bisection more
powerful).
Regarding the `ValueCache` change:
> ===================================================================
> --- lib/Analysis/LazyValueInfo.cpp
> +++ lib/Analysis/LazyValueInfo.cpp
> @@ -315,17 +315,18 @@
> /// This is all of the cached block information for exactly one Value*.
> /// The entries are sorted by the BasicBlock* of the
> /// entries, allowing us to do a lookup with a binary search.
> - typedef std::map<AssertingVH<BasicBlock>, LVILatticeVal> ValueCacheEntryTy;
> + typedef DenseMap<AssertingVH<BasicBlock>, LVILatticeVal> ValueCacheEntryTy;
DenseMap allocates space for 64 entries on construction...
> /// This is all of the cached information for all values,
> /// mapped from Value* to key information.
> std::map<LVIValueHandle, ValueCacheEntryTy> ValueCache;
>
Now each entry in the `ValueCache` will have a huge memory cost, even if
the `ValueCacheEntryTy::second` only has a couple of items in it. Do
you know what the typical size is? Would a `SmallDenseMap<>` be
appropriate? (If they're usually close to empty, then maybe
`SmallDenseMap<..., 4>`?)
More information about the llvm-commits
mailing list