maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/ThinLTO/X86/alias_import.ll

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

166 lines
9.0 KiB
LLVM
Raw Normal View History

ThinLTO: Resolve linkonce_odr aliases just like functions This help to streamline the process of handling importing since we don't need to special case alias everywhere: just like linkonce_odr function, make sure at least one alias is emitted by turning it weak. Differential Revision: http://reviews.llvm.org/D19308 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266958
2016-04-21 13:47:17 +08:00
; RUN: opt -module-summary %s -o %t1.bc
; RUN: opt -module-summary %p/Inputs/alias_import.ll -o %t2.bc
; RUN: llvm-lto -thinlto-action=thinlink -o %t.index.bc %t1.bc %t2.bc
[FileCheck] Add -allow-deprecated-dag-overlap to failing llvm tests See https://reviews.llvm.org/D47106 for details. Reviewed By: probinson Differential Revision: https://reviews.llvm.org/D47171 This commit drops that patch's changes to: llvm/test/CodeGen/NVPTX/f16x2-instructions.ll llvm/test/CodeGen/NVPTX/param-load-store.ll For some reason, the dos line endings there prevent me from commiting via the monorepo. A follow-up commit (not via the monorepo) will finish the patch. llvm-svn: 336843
2018-07-12 04:25:49 +08:00
; RUN: llvm-lto -thinlto-action=promote -thinlto-index %t.index.bc %t2.bc -o - | llvm-dis -o - | FileCheck -allow-deprecated-dag-overlap %s --check-prefix=PROMOTE
; RUN: llvm-lto -thinlto-action=import -thinlto-index %t.index.bc %t1.bc -o - | llvm-dis -o - | FileCheck -allow-deprecated-dag-overlap %s --check-prefix=IMPORT
ThinLTO: Resolve linkonce_odr aliases just like functions This help to streamline the process of handling importing since we don't need to special case alias everywhere: just like linkonce_odr function, make sure at least one alias is emitted by turning it weak. Differential Revision: http://reviews.llvm.org/D19308 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266958
2016-04-21 13:47:17 +08:00
[ThinLTO] Enable importing of aliases as copy of aliasee Summary: This implements a missing feature to allow importing of aliases, which was previously disabled because alias cannot be available_externally. We instead import an alias as a copy of its aliasee. Some additional work was required in the IndexBitcodeWriter for the distributed build case, to ensure that the aliasee has a value id in the distributed index file (i.e. even when it is not being imported directly). This is a performance win in codes that have many aliases, e.g. C++ applications that have many constructor and destructor aliases. Reviewers: pcc Subscribers: mehdi_amini, inglorion, eraman, llvm-commits Differential Revision: https://reviews.llvm.org/D40747 llvm-svn: 320895
2017-12-16 08:18:12 +08:00
; Alias can't point to "available_externally", so they are implemented by
; importing the alias as an available_externally definition copied from the
; aliasee's body.
ThinLTO: Resolve linkonce_odr aliases just like functions This help to streamline the process of handling importing since we don't need to special case alias everywhere: just like linkonce_odr function, make sure at least one alias is emitted by turning it weak. Differential Revision: http://reviews.llvm.org/D19308 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266958
2016-04-21 13:47:17 +08:00
; PROMOTE-DAG: @globalfuncAlias = alias void (...), bitcast (void ()* @globalfunc to void (...)*)
; PROMOTE-DAG: @globalfuncWeakAlias = weak alias void (...), bitcast (void ()* @globalfunc to void (...)*)
ThinLTO: Do not take into account whether a definition has multiple copies when promoting. We currently do not touch a symbol's linkage in the case where a definition has a single copy. However, this code is effectively unnecessary: either the definition is not exported, in which case the internalize phase sets its linkage to internal, or it is exported, in which case we need to promote linkage to weak. Those two cases are already handled by existing code. I believe that the only real functional change here is in the case where we have a single definition which does not prevail (e.g. because the definition in a native object file prevails). In that case we now lower linkage to available_externally following the existing code path for that case. As a result we can remove the isExported function parameter from the thinLTOResolveWeakForLinkerInIndex function. Differential Revision: http://reviews.llvm.org/D21883 llvm-svn: 274784
2016-07-08 02:31:51 +08:00
; PROMOTE-DAG: @globalfuncLinkonceAlias = weak alias void (...), bitcast (void ()* @globalfunc to void (...)*)
ThinLTO: Resolve linkonce_odr aliases just like functions This help to streamline the process of handling importing since we don't need to special case alias everywhere: just like linkonce_odr function, make sure at least one alias is emitted by turning it weak. Differential Revision: http://reviews.llvm.org/D19308 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266958
2016-04-21 13:47:17 +08:00
; PROMOTE-DAG: @globalfuncWeakODRAlias = weak_odr alias void (...), bitcast (void ()* @globalfunc to void (...)*)
ThinLTO: Do not take into account whether a definition has multiple copies when promoting. We currently do not touch a symbol's linkage in the case where a definition has a single copy. However, this code is effectively unnecessary: either the definition is not exported, in which case the internalize phase sets its linkage to internal, or it is exported, in which case we need to promote linkage to weak. Those two cases are already handled by existing code. I believe that the only real functional change here is in the case where we have a single definition which does not prevail (e.g. because the definition in a native object file prevails). In that case we now lower linkage to available_externally following the existing code path for that case. As a result we can remove the isExported function parameter from the thinLTOResolveWeakForLinkerInIndex function. Differential Revision: http://reviews.llvm.org/D21883 llvm-svn: 274784
2016-07-08 02:31:51 +08:00
; PROMOTE-DAG: @globalfuncLinkonceODRAlias = weak_odr alias void (...), bitcast (void ()* @globalfunc to void (...)*)
[ThinLTO] Only promote exported locals as marked in index Summary: We have always speculatively promoted all renamable local values (except const non-address taken variables) for both the exporting and importing module. We would then internalize them back based on the ThinLink results if they weren't actually exported. This is inefficient, and results in unnecessary renames. It also meant we had to check the non-renamability of a value in the summary, which was already checked during function importing analysis in the ThinLink. Made renameModuleForThinLTO (which does the promotion/renaming) instead use the index when exporting, to avoid unnecessary renames/promotions. For importing modules, we can simply promoted all values as any local we import by definition is exported and needs promotion. This required changes to the method used by the FunctionImport pass (only invoked from 'opt' for testing) and when invoked from llvm-link, since neither does a ThinLink. We simply conservatively mark all locals in the index as promoted, which preserves the current aggressive promotion behavior. I also needed to change an llvm-lto based test where we had previously been aggressively promoting values that weren't importable (aliasees), but now will not promote. Reviewers: mehdi_amini Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D26467 llvm-svn: 286871
2016-11-15 03:21:41 +08:00
; PROMOTE-DAG: @internalfuncAlias = alias void (...), bitcast (void ()* @internalfunc to void (...)*)
; PROMOTE-DAG: @internalfuncWeakAlias = weak alias void (...), bitcast (void ()* @internalfunc to void (...)*)
; PROMOTE-DAG: @internalfuncLinkonceAlias = weak alias void (...), bitcast (void ()* @internalfunc to void (...)*)
; PROMOTE-DAG: @internalfuncWeakODRAlias = weak_odr alias void (...), bitcast (void ()* @internalfunc to void (...)*)
; PROMOTE-DAG: @internalfuncLinkonceODRAlias = weak_odr alias void (...), bitcast (void ()* @internalfunc to void (...)*)
ThinLTO: Resolve linkonce_odr aliases just like functions This help to streamline the process of handling importing since we don't need to special case alias everywhere: just like linkonce_odr function, make sure at least one alias is emitted by turning it weak. Differential Revision: http://reviews.llvm.org/D19308 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266958
2016-04-21 13:47:17 +08:00
; PROMOTE-DAG: @linkoncefuncAlias = alias void (...), bitcast (void ()* @linkoncefunc to void (...)*)
; PROMOTE-DAG: @linkoncefuncWeakAlias = weak alias void (...), bitcast (void ()* @linkoncefunc to void (...)*)
ThinLTO: Do not take into account whether a definition has multiple copies when promoting. We currently do not touch a symbol's linkage in the case where a definition has a single copy. However, this code is effectively unnecessary: either the definition is not exported, in which case the internalize phase sets its linkage to internal, or it is exported, in which case we need to promote linkage to weak. Those two cases are already handled by existing code. I believe that the only real functional change here is in the case where we have a single definition which does not prevail (e.g. because the definition in a native object file prevails). In that case we now lower linkage to available_externally following the existing code path for that case. As a result we can remove the isExported function parameter from the thinLTOResolveWeakForLinkerInIndex function. Differential Revision: http://reviews.llvm.org/D21883 llvm-svn: 274784
2016-07-08 02:31:51 +08:00
; PROMOTE-DAG: @linkoncefuncLinkonceAlias = weak alias void (...), bitcast (void ()* @linkoncefunc to void (...)*)
ThinLTO: Resolve linkonce_odr aliases just like functions This help to streamline the process of handling importing since we don't need to special case alias everywhere: just like linkonce_odr function, make sure at least one alias is emitted by turning it weak. Differential Revision: http://reviews.llvm.org/D19308 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266958
2016-04-21 13:47:17 +08:00
; PROMOTE-DAG: @linkoncefuncWeakODRAlias = weak_odr alias void (...), bitcast (void ()* @linkoncefunc to void (...)*)
ThinLTO: Do not take into account whether a definition has multiple copies when promoting. We currently do not touch a symbol's linkage in the case where a definition has a single copy. However, this code is effectively unnecessary: either the definition is not exported, in which case the internalize phase sets its linkage to internal, or it is exported, in which case we need to promote linkage to weak. Those two cases are already handled by existing code. I believe that the only real functional change here is in the case where we have a single definition which does not prevail (e.g. because the definition in a native object file prevails). In that case we now lower linkage to available_externally following the existing code path for that case. As a result we can remove the isExported function parameter from the thinLTOResolveWeakForLinkerInIndex function. Differential Revision: http://reviews.llvm.org/D21883 llvm-svn: 274784
2016-07-08 02:31:51 +08:00
; PROMOTE-DAG: @linkoncefuncLinkonceODRAlias = weak_odr alias void (...), bitcast (void ()* @linkoncefunc to void (...)*)
ThinLTO: Resolve linkonce_odr aliases just like functions This help to streamline the process of handling importing since we don't need to special case alias everywhere: just like linkonce_odr function, make sure at least one alias is emitted by turning it weak. Differential Revision: http://reviews.llvm.org/D19308 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266958
2016-04-21 13:47:17 +08:00
; PROMOTE-DAG: @weakfuncAlias = alias void (...), bitcast (void ()* @weakfunc to void (...)*)
; PROMOTE-DAG: @weakfuncWeakAlias = weak alias void (...), bitcast (void ()* @weakfunc to void (...)*)
ThinLTO: Do not take into account whether a definition has multiple copies when promoting. We currently do not touch a symbol's linkage in the case where a definition has a single copy. However, this code is effectively unnecessary: either the definition is not exported, in which case the internalize phase sets its linkage to internal, or it is exported, in which case we need to promote linkage to weak. Those two cases are already handled by existing code. I believe that the only real functional change here is in the case where we have a single definition which does not prevail (e.g. because the definition in a native object file prevails). In that case we now lower linkage to available_externally following the existing code path for that case. As a result we can remove the isExported function parameter from the thinLTOResolveWeakForLinkerInIndex function. Differential Revision: http://reviews.llvm.org/D21883 llvm-svn: 274784
2016-07-08 02:31:51 +08:00
; PROMOTE-DAG: @weakfuncLinkonceAlias = weak alias void (...), bitcast (void ()* @weakfunc to void (...)*)
ThinLTO: Resolve linkonce_odr aliases just like functions This help to streamline the process of handling importing since we don't need to special case alias everywhere: just like linkonce_odr function, make sure at least one alias is emitted by turning it weak. Differential Revision: http://reviews.llvm.org/D19308 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266958
2016-04-21 13:47:17 +08:00
; PROMOTE-DAG: @weakfuncWeakODRAlias = weak_odr alias void (...), bitcast (void ()* @weakfunc to void (...)*)
ThinLTO: Do not take into account whether a definition has multiple copies when promoting. We currently do not touch a symbol's linkage in the case where a definition has a single copy. However, this code is effectively unnecessary: either the definition is not exported, in which case the internalize phase sets its linkage to internal, or it is exported, in which case we need to promote linkage to weak. Those two cases are already handled by existing code. I believe that the only real functional change here is in the case where we have a single definition which does not prevail (e.g. because the definition in a native object file prevails). In that case we now lower linkage to available_externally following the existing code path for that case. As a result we can remove the isExported function parameter from the thinLTOResolveWeakForLinkerInIndex function. Differential Revision: http://reviews.llvm.org/D21883 llvm-svn: 274784
2016-07-08 02:31:51 +08:00
; PROMOTE-DAG: @weakfuncLinkonceODRAlias = weak_odr alias void (...), bitcast (void ()* @weakfunc to void (...)*)
ThinLTO: Resolve linkonce_odr aliases just like functions This help to streamline the process of handling importing since we don't need to special case alias everywhere: just like linkonce_odr function, make sure at least one alias is emitted by turning it weak. Differential Revision: http://reviews.llvm.org/D19308 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266958
2016-04-21 13:47:17 +08:00
; PROMOTE-DAG: @weakODRfuncAlias = alias void (...), bitcast (void ()* @weakODRfunc to void (...)*)
; PROMOTE-DAG: @weakODRfuncWeakAlias = weak alias void (...), bitcast (void ()* @weakODRfunc to void (...)*)
ThinLTO: Do not take into account whether a definition has multiple copies when promoting. We currently do not touch a symbol's linkage in the case where a definition has a single copy. However, this code is effectively unnecessary: either the definition is not exported, in which case the internalize phase sets its linkage to internal, or it is exported, in which case we need to promote linkage to weak. Those two cases are already handled by existing code. I believe that the only real functional change here is in the case where we have a single definition which does not prevail (e.g. because the definition in a native object file prevails). In that case we now lower linkage to available_externally following the existing code path for that case. As a result we can remove the isExported function parameter from the thinLTOResolveWeakForLinkerInIndex function. Differential Revision: http://reviews.llvm.org/D21883 llvm-svn: 274784
2016-07-08 02:31:51 +08:00
; PROMOTE-DAG: @weakODRfuncLinkonceAlias = weak alias void (...), bitcast (void ()* @weakODRfunc to void (...)*)
ThinLTO: Resolve linkonce_odr aliases just like functions This help to streamline the process of handling importing since we don't need to special case alias everywhere: just like linkonce_odr function, make sure at least one alias is emitted by turning it weak. Differential Revision: http://reviews.llvm.org/D19308 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266958
2016-04-21 13:47:17 +08:00
; PROMOTE-DAG: @weakODRfuncWeakODRAlias = weak_odr alias void (...), bitcast (void ()* @weakODRfunc to void (...)*)
ThinLTO: Do not take into account whether a definition has multiple copies when promoting. We currently do not touch a symbol's linkage in the case where a definition has a single copy. However, this code is effectively unnecessary: either the definition is not exported, in which case the internalize phase sets its linkage to internal, or it is exported, in which case we need to promote linkage to weak. Those two cases are already handled by existing code. I believe that the only real functional change here is in the case where we have a single definition which does not prevail (e.g. because the definition in a native object file prevails). In that case we now lower linkage to available_externally following the existing code path for that case. As a result we can remove the isExported function parameter from the thinLTOResolveWeakForLinkerInIndex function. Differential Revision: http://reviews.llvm.org/D21883 llvm-svn: 274784
2016-07-08 02:31:51 +08:00
; PROMOTE-DAG: @weakODRfuncLinkonceODRAlias = weak_odr alias void (...), bitcast (void ()* @weakODRfunc to void (...)*)
ThinLTO: Resolve linkonce_odr aliases just like functions This help to streamline the process of handling importing since we don't need to special case alias everywhere: just like linkonce_odr function, make sure at least one alias is emitted by turning it weak. Differential Revision: http://reviews.llvm.org/D19308 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266958
2016-04-21 13:47:17 +08:00
; PROMOTE-DAG: @linkonceODRfuncAlias = alias void (...), bitcast (void ()* @linkonceODRfunc to void (...)*)
; PROMOTE-DAG: @linkonceODRfuncWeakAlias = weak alias void (...), bitcast (void ()* @linkonceODRfunc to void (...)*)
; PROMOTE-DAG: @linkonceODRfuncWeakODRAlias = weak_odr alias void (...), bitcast (void ()* @linkonceODRfunc to void (...)*)
ThinLTO: Do not take into account whether a definition has multiple copies when promoting. We currently do not touch a symbol's linkage in the case where a definition has a single copy. However, this code is effectively unnecessary: either the definition is not exported, in which case the internalize phase sets its linkage to internal, or it is exported, in which case we need to promote linkage to weak. Those two cases are already handled by existing code. I believe that the only real functional change here is in the case where we have a single definition which does not prevail (e.g. because the definition in a native object file prevails). In that case we now lower linkage to available_externally following the existing code path for that case. As a result we can remove the isExported function parameter from the thinLTOResolveWeakForLinkerInIndex function. Differential Revision: http://reviews.llvm.org/D21883 llvm-svn: 274784
2016-07-08 02:31:51 +08:00
; PROMOTE-DAG: @linkonceODRfuncLinkonceAlias = weak alias void (...), bitcast (void ()* @linkonceODRfunc to void (...)*)
ThinLTO: Resolve linkonce_odr aliases just like functions This help to streamline the process of handling importing since we don't need to special case alias everywhere: just like linkonce_odr function, make sure at least one alias is emitted by turning it weak. Differential Revision: http://reviews.llvm.org/D19308 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266958
2016-04-21 13:47:17 +08:00
; PROMOTE-DAG: @linkonceODRfuncLinkonceODRAlias = weak_odr alias void (...), bitcast (void ()* @linkonceODRfunc to void (...)*)
[ThinLTO] Use original alias visibility when importing Summary: When we import an alias, we do so by making a clone of the aliasee. Just as this clone uses the original alias name and linkage, it should also use the same visibility (not the aliasee's visibility). Otherwise, linker behavior is affected (e.g. if the aliasee was hidden, but the alias is not, the resulting imported clone should not be hidden, otherwise the linker will make the final symbol hidden which is incorrect). Reviewers: wmi Subscribers: mehdi_amini, inglorion, eraman, steven_wu, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62535 llvm-svn: 361989
2019-05-30 00:50:46 +08:00
; PROMOTE-DAG: define hidden void @globalfunc()
[ThinLTO] Only promote exported locals as marked in index Summary: We have always speculatively promoted all renamable local values (except const non-address taken variables) for both the exporting and importing module. We would then internalize them back based on the ThinLink results if they weren't actually exported. This is inefficient, and results in unnecessary renames. It also meant we had to check the non-renamability of a value in the summary, which was already checked during function importing analysis in the ThinLink. Made renameModuleForThinLTO (which does the promotion/renaming) instead use the index when exporting, to avoid unnecessary renames/promotions. For importing modules, we can simply promoted all values as any local we import by definition is exported and needs promotion. This required changes to the method used by the FunctionImport pass (only invoked from 'opt' for testing) and when invoked from llvm-link, since neither does a ThinLink. We simply conservatively mark all locals in the index as promoted, which preserves the current aggressive promotion behavior. I also needed to change an llvm-lto based test where we had previously been aggressively promoting values that weren't importable (aliasees), but now will not promote. Reviewers: mehdi_amini Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D26467 llvm-svn: 286871
2016-11-15 03:21:41 +08:00
; PROMOTE-DAG: define internal void @internalfunc()
[ThinLTO] Correctly resolve linkonce when importing aliasee Summary: When we have an aliasee that is linkonce, while we can't convert the non-prevailing copies to available_externally, we still need to convert the prevailing copy to weak. If a reference to the aliasee is exported, not converting a copy to weak will result in undefined references when the linkonce is removed in its original module. Add a new test and update existing tests. Reviewers: mehdi_amini Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D26076 llvm-svn: 285512
2016-10-30 13:15:23 +08:00
; PROMOTE-DAG: define weak_odr void @linkonceODRfunc()
ThinLTO: Resolve linkonce_odr aliases just like functions This help to streamline the process of handling importing since we don't need to special case alias everywhere: just like linkonce_odr function, make sure at least one alias is emitted by turning it weak. Differential Revision: http://reviews.llvm.org/D19308 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266958
2016-04-21 13:47:17 +08:00
; PROMOTE-DAG: define weak_odr void @weakODRfunc()
[ThinLTO] Correctly resolve linkonce when importing aliasee Summary: When we have an aliasee that is linkonce, while we can't convert the non-prevailing copies to available_externally, we still need to convert the prevailing copy to weak. If a reference to the aliasee is exported, not converting a copy to weak will result in undefined references when the linkonce is removed in its original module. Add a new test and update existing tests. Reviewers: mehdi_amini Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D26076 llvm-svn: 285512
2016-10-30 13:15:23 +08:00
; PROMOTE-DAG: define weak void @linkoncefunc()
ThinLTO: Resolve linkonce_odr aliases just like functions This help to streamline the process of handling importing since we don't need to special case alias everywhere: just like linkonce_odr function, make sure at least one alias is emitted by turning it weak. Differential Revision: http://reviews.llvm.org/D19308 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266958
2016-04-21 13:47:17 +08:00
; PROMOTE-DAG: define weak void @weakfunc()
[ThinLTO] Enable importing of aliases as copy of aliasee Summary: This implements a missing feature to allow importing of aliases, which was previously disabled because alias cannot be available_externally. We instead import an alias as a copy of its aliasee. Some additional work was required in the IndexBitcodeWriter for the distributed build case, to ensure that the aliasee has a value id in the distributed index file (i.e. even when it is not being imported directly). This is a performance win in codes that have many aliases, e.g. C++ applications that have many constructor and destructor aliases. Reviewers: pcc Subscribers: mehdi_amini, inglorion, eraman, llvm-commits Differential Revision: https://reviews.llvm.org/D40747 llvm-svn: 320895
2017-12-16 08:18:12 +08:00
; On the import side now, verify that aliases are imported unless they
; are preemptible (non-ODR weak/linkonce).
; IMPORT-DAG: declare void @linkonceODRfuncWeakAlias
; IMPORT-DAG: declare void @linkonceODRfuncLinkonceAlias
; IMPORT-DAG: define available_externally void @linkonceODRfuncAlias
; IMPORT-DAG: define available_externally void @linkonceODRfuncWeakODRAlias
; IMPORT-DAG: define available_externally void @linkonceODRfuncLinkonceODRAlias
[ThinLTO] Use original alias visibility when importing Summary: When we import an alias, we do so by making a clone of the aliasee. Just as this clone uses the original alias name and linkage, it should also use the same visibility (not the aliasee's visibility). Otherwise, linker behavior is affected (e.g. if the aliasee was hidden, but the alias is not, the resulting imported clone should not be hidden, otherwise the linker will make the final symbol hidden which is incorrect). Reviewers: wmi Subscribers: mehdi_amini, inglorion, eraman, steven_wu, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62535 llvm-svn: 361989
2019-05-30 00:50:46 +08:00
; IMPORT-DAG: define available_externally dso_local void @globalfuncAlias()
ThinLTO: Resolve linkonce_odr aliases just like functions This help to streamline the process of handling importing since we don't need to special case alias everywhere: just like linkonce_odr function, make sure at least one alias is emitted by turning it weak. Differential Revision: http://reviews.llvm.org/D19308 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266958
2016-04-21 13:47:17 +08:00
; IMPORT-DAG: declare void @globalfuncWeakAlias()
; IMPORT-DAG: declare void @globalfuncLinkonceAlias()
[ThinLTO] Use original alias visibility when importing Summary: When we import an alias, we do so by making a clone of the aliasee. Just as this clone uses the original alias name and linkage, it should also use the same visibility (not the aliasee's visibility). Otherwise, linker behavior is affected (e.g. if the aliasee was hidden, but the alias is not, the resulting imported clone should not be hidden, otherwise the linker will make the final symbol hidden which is incorrect). Reviewers: wmi Subscribers: mehdi_amini, inglorion, eraman, steven_wu, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62535 llvm-svn: 361989
2019-05-30 00:50:46 +08:00
; IMPORT-DAG: define available_externally dso_local void @globalfuncWeakODRAlias()
; IMPORT-DAG: define available_externally dso_local void @globalfuncLinkonceODRAlias()
Make internal/private GVs implicitly dso_local. While updating clang tests for having clang set dso_local I noticed that: - There are *a lot* of tests to update. - Many of the updates are redundant. They are redundant because a GV is "obviously dso_local". This patch starts formalizing that a bit by requiring that internal and private GVs be dso_local too. Since they all are, we don't have to print dso_local to the textual representation, making it a bit more compact and easier to read. llvm-svn: 322317
2018-01-12 06:15:05 +08:00
; IMPORT-DAG: define available_externally dso_local void @internalfuncAlias()
ThinLTO: Resolve linkonce_odr aliases just like functions This help to streamline the process of handling importing since we don't need to special case alias everywhere: just like linkonce_odr function, make sure at least one alias is emitted by turning it weak. Differential Revision: http://reviews.llvm.org/D19308 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266958
2016-04-21 13:47:17 +08:00
; IMPORT-DAG: declare void @internalfuncWeakAlias()
; IMPORT-DAG: declare void @internalfuncLinkonceAlias()
Make internal/private GVs implicitly dso_local. While updating clang tests for having clang set dso_local I noticed that: - There are *a lot* of tests to update. - Many of the updates are redundant. They are redundant because a GV is "obviously dso_local". This patch starts formalizing that a bit by requiring that internal and private GVs be dso_local too. Since they all are, we don't have to print dso_local to the textual representation, making it a bit more compact and easier to read. llvm-svn: 322317
2018-01-12 06:15:05 +08:00
; IMPORT-DAG: define available_externally dso_local void @internalfuncWeakODRAlias()
; IMPORT-DAG: define available_externally dso_local void @internalfuncLinkonceODRAlias()
[ThinLTO] Enable importing of aliases as copy of aliasee Summary: This implements a missing feature to allow importing of aliases, which was previously disabled because alias cannot be available_externally. We instead import an alias as a copy of its aliasee. Some additional work was required in the IndexBitcodeWriter for the distributed build case, to ensure that the aliasee has a value id in the distributed index file (i.e. even when it is not being imported directly). This is a performance win in codes that have many aliases, e.g. C++ applications that have many constructor and destructor aliases. Reviewers: pcc Subscribers: mehdi_amini, inglorion, eraman, llvm-commits Differential Revision: https://reviews.llvm.org/D40747 llvm-svn: 320895
2017-12-16 08:18:12 +08:00
; IMPORT-DAG: define available_externally void @weakODRfuncAlias()
ThinLTO: Resolve linkonce_odr aliases just like functions This help to streamline the process of handling importing since we don't need to special case alias everywhere: just like linkonce_odr function, make sure at least one alias is emitted by turning it weak. Differential Revision: http://reviews.llvm.org/D19308 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266958
2016-04-21 13:47:17 +08:00
; IMPORT-DAG: declare void @weakODRfuncWeakAlias()
; IMPORT-DAG: declare void @weakODRfuncLinkonceAlias()
[ThinLTO] Enable importing of aliases as copy of aliasee Summary: This implements a missing feature to allow importing of aliases, which was previously disabled because alias cannot be available_externally. We instead import an alias as a copy of its aliasee. Some additional work was required in the IndexBitcodeWriter for the distributed build case, to ensure that the aliasee has a value id in the distributed index file (i.e. even when it is not being imported directly). This is a performance win in codes that have many aliases, e.g. C++ applications that have many constructor and destructor aliases. Reviewers: pcc Subscribers: mehdi_amini, inglorion, eraman, llvm-commits Differential Revision: https://reviews.llvm.org/D40747 llvm-svn: 320895
2017-12-16 08:18:12 +08:00
; IMPORT-DAG: define available_externally void @weakODRfuncWeakODRAlias()
; IMPORT-DAG: define available_externally void @weakODRfuncLinkonceODRAlias()
; IMPORT-DAG: define available_externally void @linkoncefuncAlias()
ThinLTO: Resolve linkonce_odr aliases just like functions This help to streamline the process of handling importing since we don't need to special case alias everywhere: just like linkonce_odr function, make sure at least one alias is emitted by turning it weak. Differential Revision: http://reviews.llvm.org/D19308 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266958
2016-04-21 13:47:17 +08:00
; IMPORT-DAG: declare void @linkoncefuncWeakAlias()
; IMPORT-DAG: declare void @linkoncefuncLinkonceAlias()
[ThinLTO] Enable importing of aliases as copy of aliasee Summary: This implements a missing feature to allow importing of aliases, which was previously disabled because alias cannot be available_externally. We instead import an alias as a copy of its aliasee. Some additional work was required in the IndexBitcodeWriter for the distributed build case, to ensure that the aliasee has a value id in the distributed index file (i.e. even when it is not being imported directly). This is a performance win in codes that have many aliases, e.g. C++ applications that have many constructor and destructor aliases. Reviewers: pcc Subscribers: mehdi_amini, inglorion, eraman, llvm-commits Differential Revision: https://reviews.llvm.org/D40747 llvm-svn: 320895
2017-12-16 08:18:12 +08:00
; IMPORT-DAG: define available_externally void @linkoncefuncWeakODRAlias()
; IMPORT-DAG: define available_externally void @linkoncefuncLinkonceODRAlias()
; IMPORT-DAG: define available_externally void @weakfuncAlias()
ThinLTO: Resolve linkonce_odr aliases just like functions This help to streamline the process of handling importing since we don't need to special case alias everywhere: just like linkonce_odr function, make sure at least one alias is emitted by turning it weak. Differential Revision: http://reviews.llvm.org/D19308 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266958
2016-04-21 13:47:17 +08:00
; IMPORT-DAG: declare void @weakfuncWeakAlias()
; IMPORT-DAG: declare void @weakfuncLinkonceAlias()
[ThinLTO] Enable importing of aliases as copy of aliasee Summary: This implements a missing feature to allow importing of aliases, which was previously disabled because alias cannot be available_externally. We instead import an alias as a copy of its aliasee. Some additional work was required in the IndexBitcodeWriter for the distributed build case, to ensure that the aliasee has a value id in the distributed index file (i.e. even when it is not being imported directly). This is a performance win in codes that have many aliases, e.g. C++ applications that have many constructor and destructor aliases. Reviewers: pcc Subscribers: mehdi_amini, inglorion, eraman, llvm-commits Differential Revision: https://reviews.llvm.org/D40747 llvm-svn: 320895
2017-12-16 08:18:12 +08:00
; IMPORT-DAG: define available_externally void @weakfuncWeakODRAlias()
; IMPORT-DAG: define available_externally void @weakfuncLinkonceODRAlias()
; IMPORT-DAG: define available_externally void @linkonceODRfuncAlias()
ThinLTO: Don't import aliases of any kind (even linkonce_odr) Summary: Until a more advanced version of importing can be implemented for aliases (one that imports an alias as an available_externally definition of the aliasee), skip the narrow subset of cases that was possible but came at a cost: aliases of linkonce_odr functions could be imported because the linkonce_odr function could be safely duplicated from the source module. This came/comes at the cost of not being able to 'home' imported linkonce functions (they had to be emitted linkonce_odr in all the destination modules (even if they weren't used by an alias) rather than as available_externally - causing extra object size). Tangentially, this also was the only reason ThinLTO would emit multiple CUs in to the resulting DWARF - which happens to be a problem for Fission (there's a fix for this in GDB but not released yet, etc). (actually it's not the only reason - but I'm sending a patch to fix the other reason shortly) There's no reason to believe this particularly narrow alias importing was especially/meaningfully important, only that it was /possible/ to implement in this way. When a more general solution is done, it should still satisfy the DWARF concerns above, since the import will still be available_externally, and thus not create extra CUs. Since now all aliases are treated the same, I removed/simplified some test cases since they were testing corner cases where there are no longer any corners. Reviewers: tejohnson, mehdi_amini Differential Revision: https://reviews.llvm.org/D35875 llvm-svn: 309278
2017-07-27 23:09:06 +08:00
; IMPORT-DAG: declare void @linkonceODRfuncWeakAlias()
[ThinLTO] Enable importing of aliases as copy of aliasee Summary: This implements a missing feature to allow importing of aliases, which was previously disabled because alias cannot be available_externally. We instead import an alias as a copy of its aliasee. Some additional work was required in the IndexBitcodeWriter for the distributed build case, to ensure that the aliasee has a value id in the distributed index file (i.e. even when it is not being imported directly). This is a performance win in codes that have many aliases, e.g. C++ applications that have many constructor and destructor aliases. Reviewers: pcc Subscribers: mehdi_amini, inglorion, eraman, llvm-commits Differential Revision: https://reviews.llvm.org/D40747 llvm-svn: 320895
2017-12-16 08:18:12 +08:00
; IMPORT-DAG: define available_externally void @linkonceODRfuncWeakODRAlias()
ThinLTO: Don't import aliases of any kind (even linkonce_odr) Summary: Until a more advanced version of importing can be implemented for aliases (one that imports an alias as an available_externally definition of the aliasee), skip the narrow subset of cases that was possible but came at a cost: aliases of linkonce_odr functions could be imported because the linkonce_odr function could be safely duplicated from the source module. This came/comes at the cost of not being able to 'home' imported linkonce functions (they had to be emitted linkonce_odr in all the destination modules (even if they weren't used by an alias) rather than as available_externally - causing extra object size). Tangentially, this also was the only reason ThinLTO would emit multiple CUs in to the resulting DWARF - which happens to be a problem for Fission (there's a fix for this in GDB but not released yet, etc). (actually it's not the only reason - but I'm sending a patch to fix the other reason shortly) There's no reason to believe this particularly narrow alias importing was especially/meaningfully important, only that it was /possible/ to implement in this way. When a more general solution is done, it should still satisfy the DWARF concerns above, since the import will still be available_externally, and thus not create extra CUs. Since now all aliases are treated the same, I removed/simplified some test cases since they were testing corner cases where there are no longer any corners. Reviewers: tejohnson, mehdi_amini Differential Revision: https://reviews.llvm.org/D35875 llvm-svn: 309278
2017-07-27 23:09:06 +08:00
; IMPORT-DAG: declare void @linkonceODRfuncLinkonceAlias()
[ThinLTO] Enable importing of aliases as copy of aliasee Summary: This implements a missing feature to allow importing of aliases, which was previously disabled because alias cannot be available_externally. We instead import an alias as a copy of its aliasee. Some additional work was required in the IndexBitcodeWriter for the distributed build case, to ensure that the aliasee has a value id in the distributed index file (i.e. even when it is not being imported directly). This is a performance win in codes that have many aliases, e.g. C++ applications that have many constructor and destructor aliases. Reviewers: pcc Subscribers: mehdi_amini, inglorion, eraman, llvm-commits Differential Revision: https://reviews.llvm.org/D40747 llvm-svn: 320895
2017-12-16 08:18:12 +08:00
; IMPORT-DAG: define available_externally void @linkonceODRfuncLinkonceODRAlias()
ThinLTO: Resolve linkonce_odr aliases just like functions This help to streamline the process of handling importing since we don't need to special case alias everywhere: just like linkonce_odr function, make sure at least one alias is emitted by turning it weak. Differential Revision: http://reviews.llvm.org/D19308 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266958
2016-04-21 13:47:17 +08:00
[ThinLTO] Fix ThinLTOCodegenerator to export llvm.used symbols Summary: Reapply r357931 with fixes to ThinLTO testcases and llvm-lto tool. ThinLTOCodeGenerator currently does not preserve llvm.used symbols and it can internalize them. In order to pass the necessary information to the legacy ThinLTOCodeGenerator, the input to the code generator is rewritten to be based on lto::InputFile. Now ThinLTO using the legacy LTO API will requires data layout in Module. "internalize" thinlto action in llvm-lto is updated to run both "promote" and "internalize" with the same configuration as ThinLTOCodeGenerator. The old "promote" + "internalize" option does not produce the same output as ThinLTOCodeGenerator. This fixes: PR41236 rdar://problem/49293439 Reviewers: tejohnson, pcc, kromanova, dexonsmith Reviewed By: tejohnson Subscribers: ormris, bd1976llvm, mehdi_amini, inglorion, eraman, hiraditya, jkorous, dexonsmith, arphaman, dang, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60421 llvm-svn: 358601
2019-04-18 01:38:09 +08:00
target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
ThinLTO: Resolve linkonce_odr aliases just like functions This help to streamline the process of handling importing since we don't need to special case alias everywhere: just like linkonce_odr function, make sure at least one alias is emitted by turning it weak. Differential Revision: http://reviews.llvm.org/D19308 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266958
2016-04-21 13:47:17 +08:00
define i32 @main() #0 {
entry:
call void @globalfuncAlias()
call void @globalfuncWeakAlias()
call void @globalfuncLinkonceAlias()
call void @globalfuncWeakODRAlias()
call void @globalfuncLinkonceODRAlias()
call void @internalfuncAlias()
call void @internalfuncWeakAlias()
call void @internalfuncLinkonceAlias()
call void @internalfuncWeakODRAlias()
call void @internalfuncLinkonceODRAlias()
call void @linkonceODRfuncAlias()
call void @linkonceODRfuncWeakAlias()
call void @linkonceODRfuncLinkonceAlias()
call void @linkonceODRfuncWeakODRAlias()
call void @linkonceODRfuncLinkonceODRAlias()
call void @weakODRfuncAlias()
call void @weakODRfuncWeakAlias()
call void @weakODRfuncLinkonceAlias()
call void @weakODRfuncWeakODRAlias()
call void @weakODRfuncLinkonceODRAlias()
call void @linkoncefuncAlias()
call void @linkoncefuncWeakAlias()
call void @linkoncefuncLinkonceAlias()
call void @linkoncefuncWeakODRAlias()
call void @linkoncefuncLinkonceODRAlias()
call void @weakfuncAlias()
call void @weakfuncWeakAlias()
call void @weakfuncLinkonceAlias()
call void @weakfuncWeakODRAlias()
call void @weakfuncLinkonceODRAlias()
ret i32 0
}
declare void @globalfuncAlias()
declare void @globalfuncWeakAlias()
declare void @globalfuncLinkonceAlias()
declare void @globalfuncWeakODRAlias()
declare void @globalfuncLinkonceODRAlias()
declare void @internalfuncAlias()
declare void @internalfuncWeakAlias()
declare void @internalfuncLinkonceAlias()
declare void @internalfuncWeakODRAlias()
declare void @internalfuncLinkonceODRAlias()
declare void @linkonceODRfuncAlias()
declare void @linkonceODRfuncWeakAlias()
declare void @linkonceODRfuncLinkonceAlias()
declare void @linkonceODRfuncWeakODRAlias()
declare void @linkonceODRfuncLinkonceODRAlias()
declare void @weakODRfuncAlias()
declare void @weakODRfuncWeakAlias()
declare void @weakODRfuncLinkonceAlias()
declare void @weakODRfuncWeakODRAlias()
declare void @weakODRfuncLinkonceODRAlias()
declare void @linkoncefuncAlias()
declare void @linkoncefuncWeakAlias()
declare void @linkoncefuncLinkonceAlias()
declare void @linkoncefuncWeakODRAlias()
declare void @linkoncefuncLinkonceODRAlias()
declare void @weakfuncAlias()
declare void @weakfuncWeakAlias()
declare void @weakfuncLinkonceAlias()
declare void @weakfuncWeakODRAlias()
declare void @weakfuncLinkonceODRAlias()