RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-23 11:13:28 +01:00
Code Issues Projects Releases Wiki Activity
fa8d730ab3
llvm-mirror/test/ThinLTO/X86/referenced_by_constant.ll

32 lines
1.7 KiB
LLVM
Raw Normal View History

Always traverse GlobalVariable initializer when computing the export list Summary: We are always importing the initializer for a GlobalVariable. So if a GlobalVariable is in the export-list, we pull in any refs as well. Reviewers: tejohnson Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D19102 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 267303
2016-04-24 01:29:24 +02:00
; Do setup work for all below tests: generate bitcode and combined index
; RUN: opt -module-summary %s -o %t.bc
; RUN: opt -module-summary %p/Inputs/referenced_by_constant.ll -o %t2.bc
; RUN: llvm-lto -thinlto-action=thinlink -o %t3.bc %t.bc %t2.bc
[ThinLTO] Always import constants This patch imports constant variables even when they can't be internalized (which results in promotion). This offers some extra constant folding opportunities. Differential revision: https://reviews.llvm.org/D70404
2020-01-15 17:29:01 +01:00
; Check the import side: we currently import bar() and also promote/import
; referenced constant objects. There is stll a room for improvement: we
; can make a local copy of someglobal and someglobal2 because they are both
; 'unnamed_addr' constants. This should eventually be done as well.
[ThinLTO] Disable "Always import constants" due to compile time issues Summary: Disable the always importing of constants introduced in D70404 by default under a new internal option, since it is causing order of magnitude compile time regressions during the thin link. Will continue investigating why the regressions occur. Reviewers: evgeny777, wmi Subscribers: mehdi_amini, inglorion, hiraditya, steven_wu, dexonsmith, arphaman, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D73724
2020-01-30 18:56:43 +01:00
; RUN: llvm-lto -thinlto-action=import -import-constants-with-refs %t.bc -thinlto-index=%t3.bc -o - | llvm-dis -o - | FileCheck %s --check-prefix=IMPORT
[ThinLTO] Always import constants This patch imports constant variables even when they can't be internalized (which results in promotion). This offers some extra constant folding opportunities. Differential revision: https://reviews.llvm.org/D70404
2020-01-15 17:29:01 +01:00
; IMPORT: @someglobal.llvm.0 = available_externally hidden unnamed_addr constant i8* bitcast (void ()* @referencedbyglobal to i8*)
; IMPORT: @someglobal2.llvm.0 = available_externally hidden unnamed_addr constant i8* bitcast (void ()* @localreferencedbyglobal.llvm.0 to i8*)
Always traverse GlobalVariable initializer when computing the export list Summary: We are always importing the initializer for a GlobalVariable. So if a GlobalVariable is in the export-list, we pull in any refs as well. Reviewers: tejohnson Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D19102 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 267303
2016-04-24 01:29:24 +02:00
; IMPORT: define available_externally void @bar()
[ThinLTO] Stop importing constant global vars as copies in the backend Summary: We were doing an optimization in the ThinLTO backends of importing constant unnamed_addr globals unconditionally as a local copy (regardless of whether the thin link decided to import them). This should be done in the thin link instead, so that resulting exported references are marked and promoted appropriately, but will need a summary enhancement to mark these variables as constant unnamed_addr. The function import logic during the thin link was trying to handle this proactively, by conservatively marking all values referenced in the initializer lists of exported global variables as also exported. However, this only handled values referenced directly from the initializer list of an exported global variable. If the value is itself a constant unnamed_addr variable, we could end up exporting its references as well. This caused multiple issues. The first is that the transitively exported references weren't promoted. Secondly, some could not be promoted/renamed (e.g. they had a section or other constraint). recursively, instead of just adding the first level of initializer list references to the ExportList directly. Remove this optimization and the associated handling in the function import backend. SPEC measurements indicate we weren't getting much from it in any case. Fixes PR31052. Reviewers: mehdi_amini Subscribers: krasin, llvm-commits Differential Revision: https://reviews.llvm.org/D26880 llvm-svn: 288446
2016-12-02 02:02:30 +01:00
; Check the export side: we currently only export bar(), which causes
; @someglobal and @someglobal2 to be promoted (see above).
[ThinLTO] Disable "Always import constants" due to compile time issues Summary: Disable the always importing of constants introduced in D70404 by default under a new internal option, since it is causing order of magnitude compile time regressions during the thin link. Will continue investigating why the regressions occur. Reviewers: evgeny777, wmi Subscribers: mehdi_amini, inglorion, hiraditya, steven_wu, dexonsmith, arphaman, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D73724
2020-01-30 18:56:43 +01:00
; RUN: llvm-lto -thinlto-action=promote -import-constants-with-refs %t2.bc -thinlto-index=%t3.bc -o - | llvm-dis -o - | FileCheck %s --check-prefix=EXPORT
Make GlobalValues with non-default visibilility dso_local. This is similar to r322317, but for visibility. It is not as neat because we have to special case extern_weak. The idea is the same as the previous change, make the transition to explicit dso_local easier for the frontends. With this they only have to add dso_local to symbols where we need some external information to decide if it is dso_local (like it being part of an ELF executable). llvm-svn: 322806
2018-01-18 03:08:23 +01:00
; EXPORT: @someglobal.llvm.0 = hidden unnamed_addr constant
; EXPORT: @someglobal2.llvm.0 = hidden unnamed_addr constant
[ThinLTO] Stop importing constant global vars as copies in the backend Summary: We were doing an optimization in the ThinLTO backends of importing constant unnamed_addr globals unconditionally as a local copy (regardless of whether the thin link decided to import them). This should be done in the thin link instead, so that resulting exported references are marked and promoted appropriately, but will need a summary enhancement to mark these variables as constant unnamed_addr. The function import logic during the thin link was trying to handle this proactively, by conservatively marking all values referenced in the initializer lists of exported global variables as also exported. However, this only handled values referenced directly from the initializer list of an exported global variable. If the value is itself a constant unnamed_addr variable, we could end up exporting its references as well. This caused multiple issues. The first is that the transitively exported references weren't promoted. Secondly, some could not be promoted/renamed (e.g. they had a section or other constraint). recursively, instead of just adding the first level of initializer list references to the ExportList directly. Remove this optimization and the associated handling in the function import backend. SPEC measurements indicate we weren't getting much from it in any case. Fixes PR31052. Reviewers: mehdi_amini Subscribers: krasin, llvm-commits Differential Revision: https://reviews.llvm.org/D26880 llvm-svn: 288446
2016-12-02 02:02:30 +01:00
; EXPORT: define void @referencedbyglobal()
[ThinLTO] Always import constants This patch imports constant variables even when they can't be internalized (which results in promotion). This offers some extra constant folding opportunities. Differential revision: https://reviews.llvm.org/D70404
2020-01-15 17:29:01 +01:00
; EXPORT: define hidden void @localreferencedbyglobal.llvm
Always traverse GlobalVariable initializer when computing the export list Summary: We are always importing the initializer for a GlobalVariable. So if a GlobalVariable is in the export-list, we pull in any refs as well. Reviewers: tejohnson Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D19102 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 267303
2016-04-24 01:29:24 +02:00
Reland "Change the X86 datalayout to add three address spaces for 32 bit signed, 32 bit unsigned, and 64 bit pointers." This reverts 57076d3199fc2b0af4a3736b7749dd5462cacda5. Original review at https://reviews.llvm.org/D64931. Review for added fix at https://reviews.llvm.org/D66843. llvm-svn: 371568
2019-09-11 01:15:38 +02:00
target datalayout = "e-m:o-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
Always traverse GlobalVariable initializer when computing the export list Summary: We are always importing the initializer for a GlobalVariable. So if a GlobalVariable is in the export-list, we pull in any refs as well. Reviewers: tejohnson Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D19102 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 267303
2016-04-24 01:29:24 +02:00
target triple = "x86_64-apple-macosx10.11.0"
declare void @bar()
define void @foo() {
call void @bar()
ret void
}
Reference in New Issue Copy Permalink