Revision tags: llvmorg-21-init, llvmorg-19.1.7 |
|
#
4312075e |
| 06-Jan-2025 |
Mircea Trofin <mtrofin@google.com> |
[nfc][thinlto] remove unnecessary return from `renameModuleForThinLTO` (#121851)
Same goes for `FunctionImportGlobalProcessing::run`.
The return value was used, but it was always `false`.
|
Revision tags: llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0 |
|
#
d4ddf06b |
| 06-Sep-2024 |
Mingming Liu <mingmingl@google.com> |
[NFCI]Remove EntryCount from FunctionSummary and clean up surrounding synthetic count passes. (#107471)
The primary motivation is to remove `EntryCount` from `FunctionSummary`.
This frees 8 bytes o
[NFCI]Remove EntryCount from FunctionSummary and clean up surrounding synthetic count passes. (#107471)
The primary motivation is to remove `EntryCount` from `FunctionSummary`.
This frees 8 bytes out of `sizeof(FunctionSummary)` (136 bytes as of
https://github.com/llvm/llvm-project/commit/64498c54831bed9cf069e0923b9b73678c6451d8).
While I'm at it, this PR clean up {SummaryBasedOptimizations,
SyntheticCountsPropagation} since they were not used and there are no
plans to further invest on them.
With this patch, bitcode writer writes a placeholder 0 at the byte
offset of `EntryCount` and bitcode reader can parse the function entry
count at the correct byte offset. Added a TODO to stop writing
`EntryCount` and bump bitcode version
show more ...
|
Revision tags: llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3 |
|
#
50724716 |
| 14-Aug-2022 |
Kazu Hirata <kazu@google.com> |
[Transforms] Qualify auto in range-based for loops (NFC)
Identified with readability-qualified-auto.
|
Revision tags: llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init |
|
#
239c831d |
| 18-Jul-2022 |
Bill Wendling <morbo@google.com> |
Add switch to use "source_filename" instead of a hash ID for globally promoted local
During LTO a local promoted to a global gets a unique suffix based on a hash of the module IR. This means that ch
Add switch to use "source_filename" instead of a hash ID for globally promoted local
During LTO a local promoted to a global gets a unique suffix based on a hash of the module IR. This means that changes in the local's module can affect the contents in another module that imported it (because the name of the imported promoted local is changed, but that doesn't reflect a real change in the importing module). So any tool that's validating changes to the importing module will see a superficial change.
Instead of using the module hash, we can use the "source_filename" if it exists to generate a unique identifier that doesn't change due to LTO shenanigans.
Differential Revision: https://reviews.llvm.org/D128863
show more ...
|
#
30402720 |
| 20-Jul-2022 |
Schrodinger ZHU Yifan <i@zhuyi.fan> |
[ThinLTO] Support aliased GlobalIFunc
Fixes https://github.com/llvm/llvm-project/issues/56290: when an ifunc is aliased in LTO, clang will attempt to create an alias summary; however, as ifunc is no
[ThinLTO] Support aliased GlobalIFunc
Fixes https://github.com/llvm/llvm-project/issues/56290: when an ifunc is aliased in LTO, clang will attempt to create an alias summary; however, as ifunc is not included in the module summary, doing so will lead to crash.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D129009
show more ...
|
Revision tags: llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2 |
|
#
a494ae43 |
| 01-Mar-2022 |
serge-sans-paille <sguelton@redhat.com> |
Cleanup includes: TransformsUtils
Estimation on the impact on preprocessor output: before: 1065307662 after: 1064800684
Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-
Cleanup includes: TransformsUtils
Estimation on the impact on preprocessor output: before: 1065307662 after: 1064800684
Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup Differential Revision: https://reviews.llvm.org/D120741
show more ...
|
Revision tags: llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init |
|
#
252a1eec |
| 03-Jul-2021 |
Fangrui Song <i@maskray.me> |
[ThinLTO] Respect ClearDSOLocalOnDeclarations for unimported functions
D74751 added `ClearDSOLocalOnDeclarations` and dropped dso_local for isDeclarationForLinker `GlobalValue`s. It missed a case fo
[ThinLTO] Respect ClearDSOLocalOnDeclarations for unimported functions
D74751 added `ClearDSOLocalOnDeclarations` and dropped dso_local for isDeclarationForLinker `GlobalValue`s. It missed a case for imported declarations (`doImportAsDefinition` is false while `isPerformingImport` is true). This can lead to a linker error for a default visibility symbol in `ld.lld -shared`.
When `ClearDSOLocalOnDeclarations` is true, we check `isPerformingImport() && !doImportAsDefinition(&GV)` along with `GV.isDeclarationForLinker()`. The new condition checks an imported declaration.
This patch fixes a `LLVMPolly.so` link error using a trunk clang -DLLVM_ENABLE_LTO=Thin.
Reviewed By: tejohnson
Differential Revision: https://reviews.llvm.org/D104986
show more ...
|
Revision tags: llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2 |
|
#
80dc0661 |
| 10-Feb-2021 |
Wei Wang <apollo.mobility@gmail.com> |
[LTO] Perform DSOLocal propagation in combined index
Perform DSOLocal propagation within summary list of every GV. This avoids the repeated query of this information during function importing.
Diff
[LTO] Perform DSOLocal propagation in combined index
Perform DSOLocal propagation within summary list of every GV. This avoids the repeated query of this information during function importing.
Differential Revision: https://reviews.llvm.org/D96398
show more ...
|
Revision tags: llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3 |
|
#
d2ef8c1f |
| 16-Feb-2020 |
Fangrui Song <maskray@google.com> |
[ThinLTO] Drop dso_local if a GlobalVariable satisfies isDeclarationForLinker()
dso_local leads to direct access even if the definition is not within this compilation unit (it is still in the same l
[ThinLTO] Drop dso_local if a GlobalVariable satisfies isDeclarationForLinker()
dso_local leads to direct access even if the definition is not within this compilation unit (it is still in the same linkage unit). On ELF, such a relocation (e.g. R_X86_64_PC32) referencing a STB_GLOBAL STV_DEFAULT object can cause a linker error in a -shared link.
If the linkage is changed to available_externally, the dso_local flag should be dropped, so that no direct access will be generated.
The current behavior is benign, because -fpic does not assume dso_local (clang/lib/CodeGen/CodeGenModule.cpp:shouldAssumeDSOLocal). If we do that for -fno-semantic-interposition (D73865), there will be an R_X86_64_PC32 linker error without this patch.
Reviewed By: tejohnson
Differential Revision: https://reviews.llvm.org/D74751
show more ...
|
Revision tags: llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2 |
|
#
e420c0c7 |
| 03-Dec-2019 |
Teresa Johnson <tejohnson@google.com> |
[ThinLTO] Fix importing of writeonly variables in distributed ThinLTO
Summary: D69561/dde5893 enabled importing of readonly variables with references, however, it introduced a bug relating to import
[ThinLTO] Fix importing of writeonly variables in distributed ThinLTO
Summary: D69561/dde5893 enabled importing of readonly variables with references, however, it introduced a bug relating to importing/internalization of writeonly variables with references.
A fix for this was added in D70006/7f92d66. But this didn't work in distributed ThinLTO mode. The reason is that the fix (importing the writeonly var with a zeroinitializer) was only applied when there were references on the writeonly var summary. In distributed ThinLTO mode, where we only have a small slice of the index, we will not have the references on the importing side if we are not importing those referenced values. Rather than changing this handshaking (which will require a lot of other changes, since that's how we know what to import in the distributed backend clang invocation), we can simply always give the writeonly variable a zero initializer.
Reviewers: evgeny777, steven_wu
Subscribers: mehdi_amini, inglorion, hiraditya, dexonsmith, arphaman, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70977
show more ...
|
Revision tags: llvmorg-9.0.1-rc1 |
|
#
cc1b0bc2 |
| 18-Nov-2019 |
Teresa Johnson <tejohnson@google.com> |
[ThinLTO] Avoid extra index lookup during promotion
Summary: Pass down the already accessed ValueInfo to shouldPromoteLocalToGlobal, to avoid an unnecessary extra index lookup.
Add some assertion c
[ThinLTO] Avoid extra index lookup during promotion
Summary: Pass down the already accessed ValueInfo to shouldPromoteLocalToGlobal, to avoid an unnecessary extra index lookup.
Add some assertion checking to confirm we have a non-empty VI when expected.
Also some misc cleanup, merging the two versions of doImportAsDefinition, since one was only called by the other, and unnecessarily passed in a member variable.
Reviewers: steven_wu, pcc, evgeny777
Reviewed By: evgeny777
Subscribers: mehdi_amini, inglorion, hiraditya, dexonsmith, arphaman, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70337
show more ...
|
#
3be6dbca |
| 18-Nov-2019 |
Teresa Johnson <tejohnson@google.com> |
[ThinLTO] Promotion handling cleanup (NFC)
Summary: Clean up the code that does GV promotion in the ThinLTO backends.
Specifically, we don't need to check whether we are importing since that is alr
[ThinLTO] Promotion handling cleanup (NFC)
Summary: Clean up the code that does GV promotion in the ThinLTO backends.
Specifically, we don't need to check whether we are importing since that is already checked and handled correctly in shouldPromoteLocalToGlobal. Simply call shouldPromoteLocalToGlobal, and if it returns true we are guaranteed that we are promoting, whether or not we are importing (or in the exporting module). This also makes the handling in getName() consistent with that in getLinkage(), which checks the DoPromote parameter regardless of whether we are importing or exporting.
Reviewers: steven_wu, pcc, evgeny777
Subscribers: mehdi_amini, inglorion, hiraditya, dexonsmith, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70327
show more ...
|
#
3d708bf5 |
| 15-Nov-2019 |
evgeny <eleviant@accesssoftek.com> |
Recommit "[ThinLTO] Add correctness check for RO/WO variable import"
ValueInfo has user-defined 'operator bool' which allows incorrect implicit conversion to GlobalValue::GUID (which is unsigned lon
Recommit "[ThinLTO] Add correctness check for RO/WO variable import"
ValueInfo has user-defined 'operator bool' which allows incorrect implicit conversion to GlobalValue::GUID (which is unsigned long). This causes bugs which are hard to track and should be removed in future.
show more ...
|
#
360f6617 |
| 14-Nov-2019 |
Benjamin Kramer <benny.kra@googlemail.com> |
Revert "[ThinLTO] Add correctness check for RO/WO variable import"
This reverts commit a2292cc537b561416c21e8d4017715d652c144cc. Breaks clang selfhost w/ThinLTO.
|
#
a2292cc5 |
| 14-Nov-2019 |
evgeny <eleviant@accesssoftek.com> |
[ThinLTO] Add correctness check for RO/WO variable import
This patch adds an assertion check for exported read/write-only variables to be also in import list for module. If they aren't we may face l
[ThinLTO] Add correctness check for RO/WO variable import
This patch adds an assertion check for exported read/write-only variables to be also in import list for module. If they aren't we may face linker errors, because read/write-only variables are internalized in their source modules. The patch also changes export lists to store ValueInfo instead of GUID for performance considerations.
Differential revision: https://reviews.llvm.org/D70128
show more ...
|
#
7f92d66f |
| 08-Nov-2019 |
evgeny <eleviant@accesssoftek.com> |
[ThinLTO] Fix bug when importing writeonly variables
Patch enables import of write-only variables with non-trivial initializers to fix linker errors. Initializers of imported variables are converted
[ThinLTO] Fix bug when importing writeonly variables
Patch enables import of write-only variables with non-trivial initializers to fix linker errors. Initializers of imported variables are converted to 'zeroinitializer' to avoid promotion of referenced objects.
Differential revision: https://reviews.llvm.org/D70006
show more ...
|
#
dde58938 |
| 07-Nov-2019 |
evgeny <eleviant@accesssoftek.com> |
[ThinLTO] Import readonly vars with refs
Patch allows importing declarations of functions and variables, referenced by the initializer of some other readonly variable. Differential revision: https:/
[ThinLTO] Import readonly vars with refs
Patch allows importing declarations of functions and variables, referenced by the initializer of some other readonly variable. Differential revision: https://reviews.llvm.org/D69561
show more ...
|
#
16ec00ee |
| 01-Nov-2019 |
Teresa Johnson <tejohnson@google.com> |
Recommit "[ThinLTO] Handle GUID collision in import global processing""
This recommits cc0b9647b76178bc3869bbfff80535ad86366472 which was reverted in d39d1a2f87aca3cfabe58ecfa5146879baa70096.
I add
Recommit "[ThinLTO] Handle GUID collision in import global processing""
This recommits cc0b9647b76178bc3869bbfff80535ad86366472 which was reverted in d39d1a2f87aca3cfabe58ecfa5146879baa70096.
I added a fix for an issue found when testing via distributed ThinLTO, and added a test case for that failure.
show more ...
|
#
d39d1a2f |
| 01-Nov-2019 |
Teresa Johnson <tejohnson@google.com> |
Revert "[LLD][ThinLTO] Handle GUID collision in import global processing"
This reverts commit cc0b9647b76178bc3869bbfff80535ad86366472.
The commit is causing a failure in internal testing. Will rec
Revert "[LLD][ThinLTO] Handle GUID collision in import global processing"
This reverts commit cc0b9647b76178bc3869bbfff80535ad86366472.
The commit is causing a failure in internal testing. Will recommit with a fix later.
show more ...
|
#
cc0b9647 |
| 25-Oct-2019 |
Teresa Johnson <tejohnson@google.com> |
[LLD][ThinLTO] Handle GUID collision in import global processing
Summary: If there are a GUID collision between two globals checking the summarylist from the import index to make assumption can be d
[LLD][ThinLTO] Handle GUID collision in import global processing
Summary: If there are a GUID collision between two globals checking the summarylist from the import index to make assumption can be dangerous.
Do not assume that a GlobalValue that has a GlobalVarSummary actually is a GlobalVariable as it can be another GlobalValue with the same GUID that the summary is connected to.
Patch by Joel Klinghed (the_jk@opera.com)
Reviewers: evgeny777, tejohnson
Reviewed By: tejohnson
Subscribers: tejohnson, dblaikie, MaskRay, mehdi_amini, inglorion, hiraditya, steven_wu, dexonsmith, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D67322
show more ...
|
#
f71f23d1 |
| 27-Sep-2019 |
Simon Pilgrim <llvm-dev@redking.me.uk> |
FunctionImportGlobalProcessing::processGlobalForThinLTO - silence static analyzer dyn_cast<FunctionSummary> null dereference warning. NFCI.
The static analyzer is warning about a potential null dere
FunctionImportGlobalProcessing::processGlobalForThinLTO - silence static analyzer dyn_cast<FunctionSummary> null dereference warning. NFCI.
The static analyzer is warning about a potential null dereference, but we should be able to use cast<FunctionSummary> directly and if not assert will fire for us.
llvm-svn: 373097
show more ...
|
Revision tags: llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3, llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4 |
|
#
3aef3528 |
| 05-Jul-2019 |
Eugene Leviant <eleviant@accesssoftek.com> |
[ThinLTO] Attempt to recommit r365188 after alignment fix
llvm-svn: 365215
|
#
e91f86f0 |
| 05-Jul-2019 |
Eugene Leviant <eleviant@accesssoftek.com> |
Reverted r365188 due to alignment problems on i686-android
llvm-svn: 365206
|
#
820cc01d |
| 05-Jul-2019 |
Eugene Leviant <eleviant@accesssoftek.com> |
[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** bi
[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
show more ...
|
#
f7e52fbd |
| 04-Jul-2019 |
Reid Kleckner <rnk@google.com> |
Revert [ThinLTO] Optimize writeonly globals out
This reverts r365040 (git commit 5cacb914758c7f436b47c8362100f10cef14bbc4)
Speculatively reverting, since this appears to have broken check-lld on Li
Revert [ThinLTO] Optimize writeonly globals out
This reverts r365040 (git commit 5cacb914758c7f436b47c8362100f10cef14bbc4)
Speculatively reverting, since this appears to have broken check-lld on Linux. Partial analysis in https://crbug.com/981168.
llvm-svn: 365097
show more ...
|