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/internalize.ll

58 lines
2.5 KiB
LLVM
Raw Normal View History

[LTO][ThinLTO] Use the linker resolutions to mark global values as dso_local. Now that we have a way to mark GlobalValues as local we can use the symbol resolutions that the linker plugin provides as part of lto/thinlto link step to refine the compilers view on what symbols will end up being local. Originally commited as r317374, but reverted in r317395 to update some missed tests. Differential Revision: https://reviews.llvm.org/D35702 llvm-svn: 317408
2017-11-05 01:04:39 +08:00
; RUN: opt -module-summary %s -o %t1.bc
Add an internalization step to the ThinLTOCodeGenerator Keeping as much as possible internal/private is known to help the optimizer. Let's try to benefit from this in ThinLTO. Note: this is early work, but is enough to build clang (and all the LLVM tools). I still need to write some lit-tests... Differential Revision: http://reviews.llvm.org/D19103 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 267317
2016-04-24 11:18:01 +08:00
; RUN: llvm-lto -thinlto-action=thinlink -o %t.index.bc %t1.bc
; RUN: llvm-lto -thinlto-action=internalize -thinlto-index %t.index.bc %t1.bc -o - | llvm-dis -o - | FileCheck %s --check-prefix=REGULAR
; RUN: llvm-lto -thinlto-action=internalize -thinlto-index %t.index.bc %t1.bc -o - --exported-symbol=foo | llvm-dis -o - | FileCheck %s --check-prefix=INTERNALIZE
[ThinLTO] Add an option to disable (thin)lto internalization. Summary: LTO and ThinLTO optimizes the IR differently. One source of differences is the amount of internalizations that can happen. Add an option to enable/disable internalization so that other differences can be studied in isolation. e.g. inlining. There are other things lto and thinlto do differently, I will add flags to enable/disable them as needed. Reviewers: tejohnson, pcc, steven_wu Subscribers: mehdi_amini, inglorion, steven_wu, dexonsmith, dang, llvm-commits Differential Revision: https://reviews.llvm.org/D53294 llvm-svn: 346140
2018-11-05 23:49:46 +08:00
; Test the enable-lto-internalization option by setting it to false.
; This makes sure indices are not marked as internallinkage and therefore
; internalization does not happen.
; RUN: llvm-lto -thinlto-action=internalize -thinlto-index %t.index.bc %t1.bc \
; RUN: -enable-lto-internalization=false --exported-symbol=foo
; RUN: llvm-dis < %t1.bc.thinlto.internalized.bc | FileCheck %s --check-prefix=INTERNALIZE-OPTION-DISABLE
llvm-lto2: Move the LTO::run() action behind a subcommand. Move LTO::run() to a "run" subcommand so that we can introduce new subcommands for testing different parts of the LTO implementation. This doesn't use llvm::cl subcommands because it doesn't appear to be currently possible to pass an argument not associated with a subcommand to a subcommand (e.g. -lto-use-new-pm, -mcpu=yonah). Differential Revision: https://reviews.llvm.org/D31410 llvm-svn: 299967
2017-04-12 02:12:00 +08:00
; RUN: llvm-lto2 run %t1.bc -o %t.o -save-temps \
[LTO] Promote before performing weak resolution Summary: This was reversed compared to ThinLTOCodeGenerator for some reason, and lead to an increased code-size on my tests. I figured that the weak resolution may internalize a linkonce function, which will be promoted immediately (and renamed), before being internalized again. Reviewers: tejohnson Subscribers: pcc, llvm-commits, mehdi_amini Differential Revision: https://reviews.llvm.org/D23632 llvm-svn: 279021
2016-08-18 08:59:24 +08:00
; RUN: -r=%t1.bc,_foo,pxl \
; RUN: -r=%t1.bc,_bar,pl \
; RUN: -r=%t1.bc,_linkonce_func,pl
[LTO] Make processing of combined module more consistent Summary: 1. Use stream 0 only for combined module. Previously if combined module was not processes ThinLTO used the stream for own output. However small changes in input, could trigger combined module and shuffle outputs making life of llvm::LTO harder. 2. Always process combined module and write output to stream 0. Processing empty combined module is cheap and allows llvm::LTO users to avoid implementing processing which is already done in llvm::LTO. Subscribers: mehdi_amini, inglorion, eraman, hiraditya Differential Revision: https://reviews.llvm.org/D41267 llvm-svn: 320905
2017-12-16 10:10:00 +08:00
; RUN: llvm-dis < %t.o.1.2.internalize.bc | FileCheck %s --check-prefix=INTERNALIZE2
[LTO] Promote before performing weak resolution Summary: This was reversed compared to ThinLTOCodeGenerator for some reason, and lead to an increased code-size on my tests. I figured that the weak resolution may internalize a linkonce function, which will be promoted immediately (and renamed), before being internalized again. Reviewers: tejohnson Subscribers: pcc, llvm-commits, mehdi_amini Differential Revision: https://reviews.llvm.org/D23632 llvm-svn: 279021
2016-08-18 08:59:24 +08:00
[ThinLTO] Add an option to disable (thin)lto internalization. Summary: LTO and ThinLTO optimizes the IR differently. One source of differences is the amount of internalizations that can happen. Add an option to enable/disable internalization so that other differences can be studied in isolation. e.g. inlining. There are other things lto and thinlto do differently, I will add flags to enable/disable them as needed. Reviewers: tejohnson, pcc, steven_wu Subscribers: mehdi_amini, inglorion, steven_wu, dexonsmith, dang, llvm-commits Differential Revision: https://reviews.llvm.org/D53294 llvm-svn: 346140
2018-11-05 23:49:46 +08:00
; Test the enable-lto-internalization option by setting it to false.
; This makes sure indices are not marked as internallinkage and therefore
; internalization does not happen.
; RUN: llvm-lto2 run %t1.bc -o %t.o -save-temps -enable-lto-internalization=false \
; RUN: -r=%t1.bc,_foo,pxl \
; RUN: -r=%t1.bc,_bar,pl \
; RUN: -r=%t1.bc,_linkonce_func,pl
; RUN: llvm-dis < %t.o.1.2.internalize.bc | FileCheck %s --check-prefix=INTERNALIZE2-OPTION-DISABLE
[LTO] Promote before performing weak resolution Summary: This was reversed compared to ThinLTOCodeGenerator for some reason, and lead to an increased code-size on my tests. I figured that the weak resolution may internalize a linkonce function, which will be promoted immediately (and renamed), before being internalized again. Reviewers: tejohnson Subscribers: pcc, llvm-commits, mehdi_amini Differential Revision: https://reviews.llvm.org/D23632 llvm-svn: 279021
2016-08-18 08:59:24 +08:00
Add an internalization step to the ThinLTOCodeGenerator Keeping as much as possible internal/private is known to help the optimizer. Let's try to benefit from this in ThinLTO. Note: this is early work, but is enough to build clang (and all the LLVM tools). I still need to write some lit-tests... Differential Revision: http://reviews.llvm.org/D19103 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 267317
2016-04-24 11:18:01 +08:00
; REGULAR: define void @foo
; REGULAR: define void @bar
[LTO] Promote before performing weak resolution Summary: This was reversed compared to ThinLTOCodeGenerator for some reason, and lead to an increased code-size on my tests. I figured that the weak resolution may internalize a linkonce function, which will be promoted immediately (and renamed), before being internalized again. Reviewers: tejohnson Subscribers: pcc, llvm-commits, mehdi_amini Differential Revision: https://reviews.llvm.org/D23632 llvm-svn: 279021
2016-08-18 08:59:24 +08:00
; REGULAR: define linkonce void @linkonce_func()
Add an internalization step to the ThinLTOCodeGenerator Keeping as much as possible internal/private is known to help the optimizer. Let's try to benefit from this in ThinLTO. Note: this is early work, but is enough to build clang (and all the LLVM tools). I still need to write some lit-tests... Differential Revision: http://reviews.llvm.org/D19103 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 267317
2016-04-24 11:18:01 +08:00
; INTERNALIZE: define void @foo
; INTERNALIZE: define internal void @bar
[LTO] Promote before performing weak resolution Summary: This was reversed compared to ThinLTOCodeGenerator for some reason, and lead to an increased code-size on my tests. I figured that the weak resolution may internalize a linkonce function, which will be promoted immediately (and renamed), before being internalized again. Reviewers: tejohnson Subscribers: pcc, llvm-commits, mehdi_amini Differential Revision: https://reviews.llvm.org/D23632 llvm-svn: 279021
2016-08-18 08:59:24 +08:00
; INTERNALIZE: define internal void @linkonce_func()
[ThinLTO] Add an option to disable (thin)lto internalization. Summary: LTO and ThinLTO optimizes the IR differently. One source of differences is the amount of internalizations that can happen. Add an option to enable/disable internalization so that other differences can be studied in isolation. e.g. inlining. There are other things lto and thinlto do differently, I will add flags to enable/disable them as needed. Reviewers: tejohnson, pcc, steven_wu Subscribers: mehdi_amini, inglorion, steven_wu, dexonsmith, dang, llvm-commits Differential Revision: https://reviews.llvm.org/D53294 llvm-svn: 346140
2018-11-05 23:49:46 +08:00
; INTERNALIZE-OPTION-DISABLE: define void @foo
; INTERNALIZE-OPTION-DISABLE: define void @bar
; INTERNALIZE-OPTION-DISABLE: define linkonce void @linkonce_func()
[LTO][ThinLTO] Use the linker resolutions to mark global values as dso_local. Now that we have a way to mark GlobalValues as local we can use the symbol resolutions that the linker plugin provides as part of lto/thinlto link step to refine the compilers view on what symbols will end up being local. Originally commited as r317374, but reverted in r317395 to update some missed tests. Differential Revision: https://reviews.llvm.org/D35702 llvm-svn: 317408
2017-11-05 01:04:39 +08:00
; INTERNALIZE2: define dso_local void @foo
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
; INTERNALIZE2: define internal void @bar
; INTERNALIZE2: define internal void @linkonce_func()
[ThinLTO] Add an option to disable (thin)lto internalization. Summary: LTO and ThinLTO optimizes the IR differently. One source of differences is the amount of internalizations that can happen. Add an option to enable/disable internalization so that other differences can be studied in isolation. e.g. inlining. There are other things lto and thinlto do differently, I will add flags to enable/disable them as needed. Reviewers: tejohnson, pcc, steven_wu Subscribers: mehdi_amini, inglorion, steven_wu, dexonsmith, dang, llvm-commits Differential Revision: https://reviews.llvm.org/D53294 llvm-svn: 346140
2018-11-05 23:49:46 +08:00
; INTERNALIZE2-OPTION-DISABLE: define dso_local void @foo
; INTERNALIZE2-OPTION-DISABLE: define dso_local void @bar
; INTERNALIZE2-OPTION-DISABLE: define weak dso_local void @linkonce_func()
Add an internalization step to the ThinLTOCodeGenerator Keeping as much as possible internal/private is known to help the optimizer. Let's try to benefit from this in ThinLTO. Note: this is early work, but is enough to build clang (and all the LLVM tools). I still need to write some lit-tests... Differential Revision: http://reviews.llvm.org/D19103 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 267317
2016-04-24 11:18:01 +08:00
target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-apple-macosx10.11.0"
define void @foo() {
[ThinLTO] - Stop internalizing and drop non-prevailing symbols. Implementation marks non-prevailing symbols as not live in the summary. Then them are dropped in backends. Fixes https://bugs.llvm.org/show_bug.cgi?id=35938 Differential revision: https://reviews.llvm.org/D42107 llvm-svn: 323633
2018-01-29 16:03:30 +08:00
call void @bar()
Add an internalization step to the ThinLTOCodeGenerator Keeping as much as possible internal/private is known to help the optimizer. Let's try to benefit from this in ThinLTO. Note: this is early work, but is enough to build clang (and all the LLVM tools). I still need to write some lit-tests... Differential Revision: http://reviews.llvm.org/D19103 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 267317
2016-04-24 11:18:01 +08:00
ret void
}
define void @bar() {
[LTO] Promote before performing weak resolution Summary: This was reversed compared to ThinLTOCodeGenerator for some reason, and lead to an increased code-size on my tests. I figured that the weak resolution may internalize a linkonce function, which will be promoted immediately (and renamed), before being internalized again. Reviewers: tejohnson Subscribers: pcc, llvm-commits, mehdi_amini Differential Revision: https://reviews.llvm.org/D23632 llvm-svn: 279021
2016-08-18 08:59:24 +08:00
call void @linkonce_func()
ret void
}
define linkonce void @linkonce_func() {
Add an internalization step to the ThinLTOCodeGenerator Keeping as much as possible internal/private is known to help the optimizer. Let's try to benefit from this in ThinLTO. Note: this is early work, but is enough to build clang (and all the LLVM tools). I still need to write some lit-tests... Differential Revision: http://reviews.llvm.org/D19103 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 267317
2016-04-24 11:18:01 +08:00
ret void
[LTO][ThinLTO] Use the linker resolutions to mark global values as dso_local. Now that we have a way to mark GlobalValues as local we can use the symbol resolutions that the linker plugin provides as part of lto/thinlto link step to refine the compilers view on what symbols will end up being local. Originally commited as r317374, but reverted in r317395 to update some missed tests. Differential Revision: https://reviews.llvm.org/D35702 llvm-svn: 317408
2017-11-05 01:04:39 +08:00
}