OSDN Git Service

[ThinLTO] Ensure we always select the same function copy to import
authorTeresa Johnson <tejohnson@google.com>
Fri, 13 Jul 2018 21:35:51 +0000 (21:35 +0000)
committerTeresa Johnson <tejohnson@google.com>
Fri, 13 Jul 2018 21:35:51 +0000 (21:35 +0000)
commit3393e5b81dbf9ffe4bb59ee023ecba492e7ae1fd
tree9ab0eba57cbb6e1d5219d08dd73c596e46b606a7
parent504eed44cd3c122eaf0b3d85ad2282c7d0e09467
[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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337050 91177308-0d34-0410-b5e6-96231b3b80d8
include/llvm/Transforms/IPO/FunctionImport.h
lib/LTO/LTO.cpp
lib/Transforms/IPO/FunctionImport.cpp
test/Transforms/FunctionImport/Inputs/funcimport_resolved1.ll [new file with mode: 0644]
test/Transforms/FunctionImport/Inputs/funcimport_resolved2.ll [new file with mode: 0644]
test/Transforms/FunctionImport/funcimport_resolved.ll [new file with mode: 0644]
tools/llvm-link/llvm-link.cpp