summaryrefslogtreecommitdiffstats
path: root/llvm/tools/llvm-link/llvm-link.cpp
diff options
context:
space:
mode:
authorTeresa Johnson <tejohnson@google.com>2018-07-13 21:35:51 +0000
committerTeresa Johnson <tejohnson@google.com>2018-07-13 21:35:51 +0000
commitd94c0594d966e9ee11aeb05e2917098bd584361e (patch)
tree3beb1a7b38a03356fe7471f465adddff3bc0f824 /llvm/tools/llvm-link/llvm-link.cpp
parentd66941fab9b562296e956274bf225ade97e7b3de (diff)
downloadbcm5719-llvm-d94c0594d966e9ee11aeb05e2917098bd584361e.tar.gz
bcm5719-llvm-d94c0594d966e9ee11aeb05e2917098bd584361e.zip
[ThinLTO] Ensure we always select the same function copy to import
In order to always import the same copy of a linkonce function, even when encountering it with different thresholds (a higher one then a lower one), keep track of the summary we decided to import. This ensures that the backend only gets a single definition to import for each GUID, so that it doesn't need to choose one. Move the largest threshold the GUID was considered for import into the current module out of the ImportMap (which is part of a larger map maintained across the whole index), and into a new map just maintained for the current module we are computing imports for. This saves some memory since we no longer have the thresholds maintained across the whole index (and throughout the in-process backends when doing a normal non-distributed ThinLTO build), at the cost of some additional information being maintained for each invocation of ComputeImportForModule (the selected summary pointer for each import). There is an additional map lookup for each callee being considered for importing, however, this was able to subsume a map lookup in the Worklist iteration that invokes computeImportForFunction. We also are able to avoid calling selectCallee if we already failed to import at the same or higher threshold. I compared the run time and peak memory for the SPEC2006 471.omnetpp benchmark (running in-process ThinLTO backends), as well as for a large internal benchmark with a distributed ThinLTO build (so just looking at the thin link time/memory). Across a number of runs with and without this change there was no significant change in the time and memory. (I tried a few other variations of the change but they also didn't improve time or peak memory). Reviewers: davidxl Subscribers: mehdi_amini, inglorion, llvm-commits Differential Revision: https://reviews.llvm.org/D48670 llvm-svn: 337050
Diffstat (limited to 'llvm/tools/llvm-link/llvm-link.cpp')
-rw-r--r--llvm/tools/llvm-link/llvm-link.cpp2
1 files changed, 1 insertions, 1 deletions
diff --git a/llvm/tools/llvm-link/llvm-link.cpp b/llvm/tools/llvm-link/llvm-link.cpp
index a50b26da731..b7a888375b3 100644
--- a/llvm/tools/llvm-link/llvm-link.cpp
+++ b/llvm/tools/llvm-link/llvm-link.cpp
@@ -262,7 +262,7 @@ static bool importFunctions(const char *argv0, Module &DestModule) {
errs() << "Importing " << FunctionName << " from " << FileName << "\n";
auto &Entry = ImportList[FileName];
- Entry.insert(std::make_pair(F->getGUID(), /* (Unused) threshold */ 1.0));
+ Entry.insert(F->getGUID());
}
auto CachedModuleLoader = [&](StringRef Identifier) {
return ModuleLoaderCache.takeModule(Identifier);
OpenPOWER on IntegriCloud