This patch uses approach introduced in D49362 to internalize variables with write-only access. Optimizer in the backend eliminates them together with corresponding stores.
Here is test result using LLVM test suite:
Paths
| Differential D63444
[ThinLTO] Optimize write-only globals out ClosedPublic Authored by evgeny777 on Jun 17 2019, 10:22 AM.
Details Summary This patch uses approach introduced in D49362 to internalize variables with write-only access. Optimizer in the backend eliminates them together with corresponding stores. Here is test result using LLVM test suite:
Diff Detail Event TimelineHerald added subscribers: dang, arphaman, dexonsmith, inglorion. · View Herald TranscriptJun 17 2019, 10:22 AM Comment Actions Sounds like an interesting optimization. Is the global storage (from the other module) also eliminated in this case? If so, can you add a testcase for that?
Comment Actions
Yes, optimized variable is internalized in both source and destination module. I'll add test case for that
Comment Actions LGTM.
This revision is now accepted and ready to land.Jun 18 2019, 8:29 AM Comment Actions I didn't get very far today, will finish the review tomorrow morning.
Comment Actions Thanks! A bunch of misc comments/suggestions below.
evgeny777 marked 18 inline comments as done. Comment ActionsAddressed review comments
Comment Actions LGTM with one minor comment nit below. Thanks!
Closed by commit rL365040: [ThinLTO] Optimize writeonly globals out (authored by evgeny777). · Explain WhyJul 3 2019, 7:14 AM This revision was automatically updated to reflect the committed changes. Comment Actions I suspect this caused https://crbug.com/981168, so I reverted this in rL365097. The steps to repro are to build LLD with thinlto and run check-lld on Linux. Some of the wasm tests fail because the WasmSym::MemoryBase global variable is wrongly internalized. I'll try to confirm that this is the culprit and provide more concrete repro steps momentarily, but I want to get things back to green before the US holidays. Comment Actions Just wanted to confirm, after reverting this, I was able to build and test LLD with ThinLTO enabled again, so this did cause the issue. Unfortunately, I have not been able to come up with a reduced test case for the issue, so I will have to leave the instructions at "run check-lld with thinlto enabled".
Revision Contents
Diff 205262 include/llvm/IR/ModuleSummaryIndex.h
lib/Analysis/ModuleSummaryAnalysis.cpp
lib/AsmParser/LLParser.cpp
lib/Bitcode/Reader/BitcodeReader.cpp
lib/Bitcode/Writer/BitcodeWriter.cpp
lib/IR/AsmWriter.cpp
lib/IR/ModuleSummaryIndex.cpp
lib/LTO/LTO.cpp
lib/Transforms/IPO/FunctionImport.cpp
lib/Transforms/Utils/FunctionImportUtils.cpp
test/Assembler/thinlto-summary.ll
test/Bitcode/summary_version.ll
test/Bitcode/thinlto-alias.ll
test/Bitcode/thinlto-alias2.ll
test/Bitcode/thinlto-function-summary-callgraph-cast.ll
test/Bitcode/thinlto-function-summary-callgraph-pgo.ll
test/Bitcode/thinlto-function-summary-callgraph-profile-summary.ll
test/Bitcode/thinlto-function-summary-callgraph-relbf.ll
test/Bitcode/thinlto-function-summary-callgraph-sample-profile-summary.ll
test/Bitcode/thinlto-function-summary-callgraph.ll
test/Bitcode/thinlto-function-summary-refgraph.ll
test/ThinLTO/X86/Inputs/dot-dumper2.ll
test/ThinLTO/X86/dot-dumper2.ll
test/ThinLTO/X86/index-const-prop.ll
test/ThinLTO/X86/index-const-prop2.ll
|
Would it be cleaner if you create a new enum bitfield for access specifier?
This should make all the method below a bit cleaner.