[PATCH] D18622: Replace the use of MaxFunctionCount module flag

[Vedant Kumar via llvm-commits]

vsk added inline comments.

================
Comment at: include/llvm/ProfileData/ProfileCommon.h:75
@@ +74,3 @@
+  // Cache of last seen module and its profile summary.
+  static std::pair<Module *, std::unique_ptr<ProfileSummary>> CachedSummary;
+
----------------
eraman wrote:
> vsk wrote:
> > eraman wrote:
> > > vsk wrote:
> > > > Hm, this won't work in multi-threaded environments.
> > > > 
> > > > You can either sink this into LLVMContext (preferred!), or make it an `llvm::ManagedStatic` defined outside of `ProfileSummary` for more visibility. If you go with the second option, you'll also need a mutex around all cache accesses.
> > > > 
> > > > Somewhere down the line you might consider making this cache some kind of (Small)?DenseMap.
> > > Yes indeed. Perhaps it is better to not cache this and instead let the clients cache the summary?
> > > 
> > > As to use of DenseMap, is this ever needed? I believe (and I may be wrong) the only place multiple modules are simultaneously present is in the LTO mode and there all modules are actually merged into one module which is where the IPO optimizations take place. 
> > > 
> > > Another crazy thought - we could just cache the ProfileSummary without any key since all modules compiled in a single process are bound to have the same profile summary (since summary is not module specific)
> > Sure, using a DenseMap is probably overkill. Having a one-entry cache seems useful though.
> > 
> > Regarding your last point: it's cheap to keep the `Module*` as a key, and keeping it makes the code less "magical" (no hidden assumptions about which Module you're referring to).
> Yeah, that's why I didn't go that route.
> 
> I don't see a way to make this part of the LLVMContextImpl since ProfileSummary is not part of Core (and we obviously don't want Core to be dependent on ProfileData). In fact that is the reason why Module's getProfileSummary returns Metadata instead of ProfileSummary. So the only way to make this work is to make it an ManagedStatic right?
There's one more possibility. What if we cache ProfileSummary objects in the clients of this API, instead of in `getProfileSummary`?

E.g we could cache the summary in `CallAnalyzer`. An `LLVMContext` should be readily available there, and that seems like the right place to put this.


http://reviews.llvm.org/D18622