summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/Utils
diff options
context:
space:
mode:
authorEugene Leviant <eleviant@accesssoftek.com>2019-07-05 12:00:10 +0000
committerEugene Leviant <eleviant@accesssoftek.com>2019-07-05 12:00:10 +0000
commit820cc01d1e65f7be7c3c27bcdcb6b8c13f4ec2e6 (patch)
tree8580e927d93c7185dd262f864c9bdeef7d450cae /llvm/lib/Transforms/Utils
parent1a517a4630ae4d9e24e991a3e6a3bf58c5dabf6d (diff)
downloadbcm5719-llvm-820cc01d1e65f7be7c3c27bcdcb6b8c13f4ec2e6.tar.gz
bcm5719-llvm-820cc01d1e65f7be7c3c27bcdcb6b8c13f4ec2e6.zip
[ThinLTO] Attempt to recommit r365040 after caching fix
It's possible that some function can load and store the same variable using the same constant expression: store %Derived* @foo, %Derived** bitcast (%Base** @bar to %Derived**) %42 = load %Derived*, %Derived** bitcast (%Base** @bar to %Derived**) The bitcast expression was mistakenly cached while processing loads, and never examined later when processing store. This caused @bar to be mistakenly treated as read-only variable. See load-store-caching.ll. llvm-svn: 365188
Diffstat (limited to 'llvm/lib/Transforms/Utils')
-rw-r--r--llvm/lib/Transforms/Utils/FunctionImportUtils.cpp13
1 files changed, 7 insertions, 6 deletions
diff --git a/llvm/lib/Transforms/Utils/FunctionImportUtils.cpp b/llvm/lib/Transforms/Utils/FunctionImportUtils.cpp
index 8e80ee2c549..c9cc0990f23 100644
--- a/llvm/lib/Transforms/Utils/FunctionImportUtils.cpp
+++ b/llvm/lib/Transforms/Utils/FunctionImportUtils.cpp
@@ -229,11 +229,11 @@ void FunctionImportGlobalProcessing::processGlobalForThinLTO(GlobalValue &GV) {
}
}
- // Mark read-only variables which can be imported with specific attribute.
- // We can't internalize them now because IRMover will fail to link variable
- // definitions to their external declarations during ThinLTO import. We'll
- // internalize read-only variables later, after import is finished.
- // See internalizeImmutableGVs.
+ // Mark read/write-only variables which can be imported with specific
+ // attribute. We can't internalize them now because IRMover will fail
+ // to link variable definitions to their external declarations during
+ // ThinLTO import. We'll internalize read-only variables later, after
+ // import is finished. See internalizeGVsAfterImport.
//
// If global value dead stripping is not enabled in summary then
// propagateConstants hasn't been run. We can't internalize GV
@@ -241,7 +241,8 @@ void FunctionImportGlobalProcessing::processGlobalForThinLTO(GlobalValue &GV) {
if (!GV.isDeclaration() && VI && ImportIndex.withGlobalValueDeadStripping()) {
const auto &SL = VI.getSummaryList();
auto *GVS = SL.empty() ? nullptr : dyn_cast<GlobalVarSummary>(SL[0].get());
- if (GVS && GVS->isReadOnly())
+ // At this stage "maybe" is "definitely"
+ if (GVS && (GVS->maybeReadOnly() || GVS->maybeWriteOnly()))
cast<GlobalVariable>(&GV)->addAttribute("thinlto-internalize");
}
OpenPOWER on IntegriCloud