[PATCH] D28549: Global DCE performance improvement
Mehdi AMINI via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Jan 12 08:42:13 PST 2017
mehdi_amini added inline comments.
================
Comment at: include/llvm/Transforms/IPO/GlobalDCE.h:36
+ SmallPtrSet<GlobalValue*, 16> LiveGVs_;
+ DenseMap<GlobalValue*, SmallPtrSet<GlobalValue*, 8>> GVDependencies_;
+ std::unordered_map<Constant*, SmallPtrSet<GlobalValue*, 8>> DependenciesCache_;
----------------
serge-sans-paille wrote:
> mehdi_amini wrote:
> > `DenseMap` is intended to contains small value, `SmallPtrSet` seems a bit `fat` here?
> >
> > Also, after reading the algorithm, this could be a vector, you should not need dedup by construction.
> According to my tests, DenseMap performs better on large test case than std::unorderd_map (by a factor of two)
>
> Correct for Set->Vector
I'm not sure what you mean by "large test case"? Do you mean lots of entries? My point was about `sizeof(Map[key])` and memory consumption.
================
Comment at: lib/Transforms/IPO/GlobalDCE.cpp:103
+ Deps.insert(LocalDeps.begin(), LocalDeps.end());
+ }
+ }
----------------
serge-sans-paille wrote:
> mehdi_amini wrote:
> > So the memorization is only used for constants (GV initializers, GEP, what else?), I'd rename it to make it explicit that this cache only applies to constants.
> >
> > Also can such constant have multiple uses? I'm failing to remember in which case right now. If they only have a single use we could just traverse and remove the memorization entirely.
> See r179458
Thanks for the pointer!
================
Comment at: lib/Transforms/IPO/GlobalDCE.cpp:126
+ for (auto &&CM : make_range(ComdatMembers_.equal_range(C)))
+ MarkLive(*CM.second, Updates);
+ }
----------------
serge-sans-paille wrote:
> mehdi_amini wrote:
> > What's the bound on the recursion? How do we guarantee that we won't run out of stack? Worth a comment.
> There's a finite number of globals and they can only be visited once because of the set check.
I'm not worried about *infinite* recursion, but *too large* recursion for the limit stack size in some environment. If the recursion is in `O(global)` that's a potential stack overflow.
Repository:
rL LLVM
https://reviews.llvm.org/D28549
More information about the llvm-commits
mailing list