GlobalValueSummaryMapTy is heavily accessed datasture. And it is large thus nlogn algorithm becomes quite expensive. Changing this to DenseMap speeds up thin-link by ~36% when building large applications.
Details
Diff Detail
- Build Status
Buildable 8140 Build 8140: arc lint + arc unit
Event Timeline
include/llvm/Analysis/ModuleSummaryAnalysis.h | ||
---|---|---|
32 | I take it this change was necessary because buildModuleSummaryIndex indirectly emits references to the elements of the map? (& DenseMap doesn't preserve reference/pointer validity over move? That surprises me slightly, but I could believe it) Is that correct? (otherwise - what's the motivation for this change?) This should be unique_ptr<ModuleSummaryIndex> not raw-but-owning pointer ModuleSummaryIndex*. | |
include/llvm/IR/ModuleSummaryIndex.h | ||
88–114 | I take it this change is necessary because ValueInfo elements are stored over mutations to the ModuleSummaryIndex & thus would invalidate references/pointers/iterators to elements & so the map lookup must be deferred? Is that correct? Is there a particular/canonical/unavoidable example of this usage? | |
lib/LTO/LTO.cpp | ||
1058 | This looks like an independent change? Should it be submitted separately with the value/memory usage/runtime performance improvements appropriately credited (so it's clear how much of the benefit is from this change as opposed to the ModuleSummaryIndex change?) |
I take it this change was necessary because buildModuleSummaryIndex indirectly emits references to the elements of the map? (& DenseMap doesn't preserve reference/pointer validity over move? That surprises me slightly, but I could believe it)
Is that correct? (otherwise - what's the motivation for this change?)
This should be unique_ptr<ModuleSummaryIndex> not raw-but-owning pointer ModuleSummaryIndex*.