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

118 lines
2.8 KiB
LLVM
Raw Normal View History

Add tests for the various emit-llvm plugin options. llvm-svn: 214102
2014-07-29 01:37:25 +08:00
; RUN: llvm-as %s -o %t.o
[gold] Consolidate the gold plugin options and actually search for a gold binary explicitly. Substitute this binary into the tests rather than just directly executing the 'ld' binary. This should allow folks to inject a cross compiling gold binary, or in my case to use a gold binary built and installed somewhere other than /usr/bin/ld. It should also allow the tests to find 'ld.gold' so that things work even if gold isn't the default on the system. I've only stubbed out support in the makefile to preserve the existing behavior with none of the fancy logic. If someone else wants to add logic here, they're welcome to do so. llvm-svn: 229251
2015-02-14 17:43:57 +08:00
; RUN: %gold -plugin %llvmshlibdir/LLVMgold.so \
Add tests for the various emit-llvm plugin options. llvm-svn: 214102
2014-07-29 01:37:25 +08:00
; RUN: --plugin-opt=emit-llvm \
; RUN: -shared %t.o -o %t2.o
Test the linker plugin handling of llvm.used. llvm-svn: 214116
2014-07-29 04:42:29 +08:00
; RUN: llvm-dis %t2.o -o - | FileCheck %s
Add tests for the various emit-llvm plugin options. llvm-svn: 214102
2014-07-29 01:37:25 +08:00
[gold] Consolidate the gold plugin options and actually search for a gold binary explicitly. Substitute this binary into the tests rather than just directly executing the 'ld' binary. This should allow folks to inject a cross compiling gold binary, or in my case to use a gold binary built and installed somewhere other than /usr/bin/ld. It should also allow the tests to find 'ld.gold' so that things work even if gold isn't the default on the system. I've only stubbed out support in the makefile to preserve the existing behavior with none of the fancy logic. If someone else wants to add logic here, they're welcome to do so. llvm-svn: 229251
2015-02-14 17:43:57 +08:00
; RUN: %gold -plugin %llvmshlibdir/LLVMgold.so \
Replace also-emit-llvm with save-temps. The also-emit-llvm option only supported getting the IR before optimizations. This patch replaces it with a more generic save-temps option that saves the IR both before and after optimizations. llvm-svn: 220885
2014-10-30 07:54:45 +08:00
; RUN: -m elf_x86_64 --plugin-opt=save-temps \
Add tests for the various emit-llvm plugin options. llvm-svn: 214102
2014-07-29 01:37:25 +08:00
; RUN: -shared %t.o -o %t3.o
Restore "Resolution-based LTO API." This restores commit r278330, with fixes for a few bot failures: - Fix a late change I had made to the save temps output file that I missed due to existing files sitting on my disk - Fix a bunch of Windows bot failures with "ambiguous call to overloaded function" due to confusion between llvm::make_unique vs std::make_unique (preface the new make_unique calls with "llvm::") - Attempt to fix a modules bot failure by adding a missing include to LTO/Config.h. Original change: Resolution-based LTO API. Summary: This introduces a resolution-based LTO API. The main advantage of this API over existing APIs is that it allows the linker to supply a resolution for each symbol in each object, rather than the combined object as a whole. This will become increasingly important for use cases such as ThinLTO which require us to process symbol resolutions in a more complicated way than just adjusting linkage. Patch by Peter Collingbourne. Reviewers: rafael, tejohnson, mehdi_amini Subscribers: lhames, tejohnson, mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D20268 llvm-svn: 278338
2016-08-11 22:58:12 +08:00
; RUN: FileCheck --check-prefix=RES %s < %t3.o.resolution.txt
Fix tests in llvm/test/tools/gold/X86 to satisfy r279014. They would unexpectedly pass if test/tools/gold/X86/Output had outputs of previous tests. llvm-svn: 279214
2016-08-19 14:44:44 +08:00
; RUN: llvm-dis %t3.o.0.2.internalize.bc -o - | FileCheck %s
; RUN: llvm-dis %t3.o.0.4.opt.bc -o - | FileCheck --check-prefix=OPT %s
; RUN: llvm-dis %t3.o.0.4.opt.bc -o - | FileCheck --check-prefix=OPT2 %s
gold-plugin: save the .o when given -save-temps. The plugin now save the bitcode before and after optimizations and the .o that is passed to the linker. llvm-svn: 239726
2015-06-15 21:36:27 +08:00
; RUN: llvm-nm %t3.o.o | FileCheck --check-prefix=NM %s
Add tests for the various emit-llvm plugin options. llvm-svn: 214102
2014-07-29 01:37:25 +08:00
Add a disable-output option to the gold plugin. This corresponds to the opt option and is handy for profiling. llvm-svn: 222687
2014-11-25 05:18:14 +08:00
; RUN: rm -f %t4.o
[gold] Consolidate the gold plugin options and actually search for a gold binary explicitly. Substitute this binary into the tests rather than just directly executing the 'ld' binary. This should allow folks to inject a cross compiling gold binary, or in my case to use a gold binary built and installed somewhere other than /usr/bin/ld. It should also allow the tests to find 'ld.gold' so that things work even if gold isn't the default on the system. I've only stubbed out support in the makefile to preserve the existing behavior with none of the fancy logic. If someone else wants to add logic here, they're welcome to do so. llvm-svn: 229251
2015-02-14 17:43:57 +08:00
; RUN: %gold -plugin %llvmshlibdir/LLVMgold.so \
Add a disable-output option to the gold plugin. This corresponds to the opt option and is handy for profiling. llvm-svn: 222687
2014-11-25 05:18:14 +08:00
; RUN: -m elf_x86_64 --plugin-opt=disable-output \
; RUN: -shared %t.o -o %t4.o
; RUN: not test -a %t4.o
gold-plugin: save the .o when given -save-temps. The plugin now save the bitcode before and after optimizations and the .o that is passed to the linker. llvm-svn: 239726
2015-06-15 21:36:27 +08:00
; NM: T f3
[LTO] Reject modules without datalayout. Also, udpate the ~60 failing tests in the tree which did not contain a valid datalayout. This fixes PR31123. lld will be updated in a following patch, immediately after this is committed. Differential Revision: https://reviews.llvm.org/D27082 llvm-svn: 289719
2016-12-15 05:57:04 +08:00
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
Add tests for the various emit-llvm plugin options. llvm-svn: 214102
2014-07-29 01:37:25 +08:00
target triple = "x86_64-unknown-linux-gnu"
Test the linker plugin handling of llvm.used. llvm-svn: 214116
2014-07-29 04:42:29 +08:00
Restore "Resolution-based LTO API." This restores commit r278330, with fixes for a few bot failures: - Fix a late change I had made to the save temps output file that I missed due to existing files sitting on my disk - Fix a bunch of Windows bot failures with "ambiguous call to overloaded function" due to confusion between llvm::make_unique vs std::make_unique (preface the new make_unique calls with "llvm::") - Attempt to fix a modules bot failure by adding a missing include to LTO/Config.h. Original change: Resolution-based LTO API. Summary: This introduces a resolution-based LTO API. The main advantage of this API over existing APIs is that it allows the linker to supply a resolution for each symbol in each object, rather than the combined object as a whole. This will become increasingly important for use cases such as ThinLTO which require us to process symbol resolutions in a more complicated way than just adjusting linkage. Patch by Peter Collingbourne. Reviewers: rafael, tejohnson, mehdi_amini Subscribers: lhames, tejohnson, mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D20268 llvm-svn: 278338
2016-08-11 22:58:12 +08:00
; CHECK-DAG: @g1 = weak_odr constant i32 32
IR: Introduce local_unnamed_addr attribute. If a local_unnamed_addr attribute is attached to a global, the address is known to be insignificant within the module. It is distinct from the existing unnamed_addr attribute in that it only describes a local property of the module rather than a global property of the symbol. This attribute is intended to be used by the code generator and LTO to allow the linker to decide whether the global needs to be in the symbol table. It is possible to exclude a global from the symbol table if three things are true: - This attribute is present on every instance of the global (which means that the normal rule that the global must have a unique address can be broken without being observable by the program by performing comparisons against the global's address) - The global has linkonce_odr linkage (which means that each linkage unit must have its own copy of the global if it requires one, and the copy in each linkage unit must be the same) - It is a constant or a function (which means that the program cannot observe that the unique-address rule has been broken by writing to the global) Although this attribute could in principle be computed from the module contents, LTO clients (i.e. linkers) will normally need to be able to compute this property as part of symbol resolution, and it would be inefficient to materialize every module just to compute it. See: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160509/356401.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160516/356738.html for earlier discussion. Part of the fix for PR27553. Differential Revision: http://reviews.llvm.org/D20348 llvm-svn: 272709
2016-06-15 05:01:22 +08:00
@g1 = linkonce_odr constant i32 32
Restore "Resolution-based LTO API." This restores commit r278330, with fixes for a few bot failures: - Fix a late change I had made to the save temps output file that I missed due to existing files sitting on my disk - Fix a bunch of Windows bot failures with "ambiguous call to overloaded function" due to confusion between llvm::make_unique vs std::make_unique (preface the new make_unique calls with "llvm::") - Attempt to fix a modules bot failure by adding a missing include to LTO/Config.h. Original change: Resolution-based LTO API. Summary: This introduces a resolution-based LTO API. The main advantage of this API over existing APIs is that it allows the linker to supply a resolution for each symbol in each object, rather than the combined object as a whole. This will become increasingly important for use cases such as ThinLTO which require us to process symbol resolutions in a more complicated way than just adjusting linkage. Patch by Peter Collingbourne. Reviewers: rafael, tejohnson, mehdi_amini Subscribers: lhames, tejohnson, mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D20268 llvm-svn: 278338
2016-08-11 22:58:12 +08:00
; CHECK-DAG: @g2 = internal constant i32 32
IR: Introduce local_unnamed_addr attribute. If a local_unnamed_addr attribute is attached to a global, the address is known to be insignificant within the module. It is distinct from the existing unnamed_addr attribute in that it only describes a local property of the module rather than a global property of the symbol. This attribute is intended to be used by the code generator and LTO to allow the linker to decide whether the global needs to be in the symbol table. It is possible to exclude a global from the symbol table if three things are true: - This attribute is present on every instance of the global (which means that the normal rule that the global must have a unique address can be broken without being observable by the program by performing comparisons against the global's address) - The global has linkonce_odr linkage (which means that each linkage unit must have its own copy of the global if it requires one, and the copy in each linkage unit must be the same) - It is a constant or a function (which means that the program cannot observe that the unique-address rule has been broken by writing to the global) Although this attribute could in principle be computed from the module contents, LTO clients (i.e. linkers) will normally need to be able to compute this property as part of symbol resolution, and it would be inefficient to materialize every module just to compute it. See: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160509/356401.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160516/356738.html for earlier discussion. Part of the fix for PR27553. Differential Revision: http://reviews.llvm.org/D20348 llvm-svn: 272709
2016-06-15 05:01:22 +08:00
@g2 = linkonce_odr local_unnamed_addr constant i32 32
; CHECK-DAG: @g3 = internal unnamed_addr constant i32 32
@g3 = linkonce_odr unnamed_addr constant i32 32
Restore "Resolution-based LTO API." This restores commit r278330, with fixes for a few bot failures: - Fix a late change I had made to the save temps output file that I missed due to existing files sitting on my disk - Fix a bunch of Windows bot failures with "ambiguous call to overloaded function" due to confusion between llvm::make_unique vs std::make_unique (preface the new make_unique calls with "llvm::") - Attempt to fix a modules bot failure by adding a missing include to LTO/Config.h. Original change: Resolution-based LTO API. Summary: This introduces a resolution-based LTO API. The main advantage of this API over existing APIs is that it allows the linker to supply a resolution for each symbol in each object, rather than the combined object as a whole. This will become increasingly important for use cases such as ThinLTO which require us to process symbol resolutions in a more complicated way than just adjusting linkage. Patch by Peter Collingbourne. Reviewers: rafael, tejohnson, mehdi_amini Subscribers: lhames, tejohnson, mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D20268 llvm-svn: 278338
2016-08-11 22:58:12 +08:00
; CHECK-DAG: @g4 = weak_odr global i32 32
IR: Introduce local_unnamed_addr attribute. If a local_unnamed_addr attribute is attached to a global, the address is known to be insignificant within the module. It is distinct from the existing unnamed_addr attribute in that it only describes a local property of the module rather than a global property of the symbol. This attribute is intended to be used by the code generator and LTO to allow the linker to decide whether the global needs to be in the symbol table. It is possible to exclude a global from the symbol table if three things are true: - This attribute is present on every instance of the global (which means that the normal rule that the global must have a unique address can be broken without being observable by the program by performing comparisons against the global's address) - The global has linkonce_odr linkage (which means that each linkage unit must have its own copy of the global if it requires one, and the copy in each linkage unit must be the same) - It is a constant or a function (which means that the program cannot observe that the unique-address rule has been broken by writing to the global) Although this attribute could in principle be computed from the module contents, LTO clients (i.e. linkers) will normally need to be able to compute this property as part of symbol resolution, and it would be inefficient to materialize every module just to compute it. See: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160509/356401.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160516/356738.html for earlier discussion. Part of the fix for PR27553. Differential Revision: http://reviews.llvm.org/D20348 llvm-svn: 272709
2016-06-15 05:01:22 +08:00
@g4 = linkonce_odr global i32 32
Restore "Resolution-based LTO API." This restores commit r278330, with fixes for a few bot failures: - Fix a late change I had made to the save temps output file that I missed due to existing files sitting on my disk - Fix a bunch of Windows bot failures with "ambiguous call to overloaded function" due to confusion between llvm::make_unique vs std::make_unique (preface the new make_unique calls with "llvm::") - Attempt to fix a modules bot failure by adding a missing include to LTO/Config.h. Original change: Resolution-based LTO API. Summary: This introduces a resolution-based LTO API. The main advantage of this API over existing APIs is that it allows the linker to supply a resolution for each symbol in each object, rather than the combined object as a whole. This will become increasingly important for use cases such as ThinLTO which require us to process symbol resolutions in a more complicated way than just adjusting linkage. Patch by Peter Collingbourne. Reviewers: rafael, tejohnson, mehdi_amini Subscribers: lhames, tejohnson, mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D20268 llvm-svn: 278338
2016-08-11 22:58:12 +08:00
; CHECK-DAG: @g5 = weak_odr global i32 32
IR: Introduce local_unnamed_addr attribute. If a local_unnamed_addr attribute is attached to a global, the address is known to be insignificant within the module. It is distinct from the existing unnamed_addr attribute in that it only describes a local property of the module rather than a global property of the symbol. This attribute is intended to be used by the code generator and LTO to allow the linker to decide whether the global needs to be in the symbol table. It is possible to exclude a global from the symbol table if three things are true: - This attribute is present on every instance of the global (which means that the normal rule that the global must have a unique address can be broken without being observable by the program by performing comparisons against the global's address) - The global has linkonce_odr linkage (which means that each linkage unit must have its own copy of the global if it requires one, and the copy in each linkage unit must be the same) - It is a constant or a function (which means that the program cannot observe that the unique-address rule has been broken by writing to the global) Although this attribute could in principle be computed from the module contents, LTO clients (i.e. linkers) will normally need to be able to compute this property as part of symbol resolution, and it would be inefficient to materialize every module just to compute it. See: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160509/356401.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160516/356738.html for earlier discussion. Part of the fix for PR27553. Differential Revision: http://reviews.llvm.org/D20348 llvm-svn: 272709
2016-06-15 05:01:22 +08:00
@g5 = linkonce_odr local_unnamed_addr global i32 32
; CHECK-DAG: @g6 = internal unnamed_addr global i32 32
@g6 = linkonce_odr unnamed_addr global i32 32
Fix handling of extern_weak. This was broken by r225983. llvm-svn: 226026
2015-01-15 03:43:32 +08:00
@g7 = extern_weak global i32
; CHECK-DAG: @g7 = extern_weak global i32
Fix linking of shared libraries. In shared libraries the plugin can see non-weak declarations that are still undefined. llvm-svn: 226031
2015-01-15 04:08:46 +08:00
@g8 = external global i32
Don't depend on the order the IR is copied. llvm-svn: 254257
2015-11-29 23:22:49 +08:00
; CHECK-DAG: define internal void @f1()
; OPT2-NOT: @f1
Add a small test showing when a linkonce_odr symbol can be hidden. llvm-svn: 214311
2014-07-30 23:31:21 +08:00
define hidden void @f1() {
Test the linker plugin handling of llvm.used. llvm-svn: 214116
2014-07-29 04:42:29 +08:00
ret void
}
Don't depend on the order the IR is copied. llvm-svn: 254257
2015-11-29 23:22:49 +08:00
; CHECK-DAG: define hidden void @f2()
; OPT-DAG: define hidden void @f2()
Add a small test showing when a linkonce_odr symbol can be hidden. llvm-svn: 214311
2014-07-30 23:31:21 +08:00
define hidden void @f2() {
Test the linker plugin handling of llvm.used. llvm-svn: 214116
2014-07-29 04:42:29 +08:00
ret void
}
Add a small test showing when a linkonce_odr symbol can be hidden. llvm-svn: 214311
2014-07-30 23:31:21 +08:00
@llvm.used = appending global [1 x i8*] [ i8* bitcast (void ()* @f2 to i8*)]
Don't depend on the order the IR is copied. llvm-svn: 254257
2015-11-29 23:22:49 +08:00
; CHECK-DAG: define void @f3()
; OPT-DAG: define void @f3()
Add a small test showing when a linkonce_odr symbol can be hidden. llvm-svn: 214311
2014-07-30 23:31:21 +08:00
define void @f3() {
call void @f4()
ret void
}
Don't depend on the order the IR is copied. llvm-svn: 254257
2015-11-29 23:22:49 +08:00
; CHECK-DAG: define internal void @f4()
; OPT2-NOT: @f4
IR: Introduce local_unnamed_addr attribute. If a local_unnamed_addr attribute is attached to a global, the address is known to be insignificant within the module. It is distinct from the existing unnamed_addr attribute in that it only describes a local property of the module rather than a global property of the symbol. This attribute is intended to be used by the code generator and LTO to allow the linker to decide whether the global needs to be in the symbol table. It is possible to exclude a global from the symbol table if three things are true: - This attribute is present on every instance of the global (which means that the normal rule that the global must have a unique address can be broken without being observable by the program by performing comparisons against the global's address) - The global has linkonce_odr linkage (which means that each linkage unit must have its own copy of the global if it requires one, and the copy in each linkage unit must be the same) - It is a constant or a function (which means that the program cannot observe that the unique-address rule has been broken by writing to the global) Although this attribute could in principle be computed from the module contents, LTO clients (i.e. linkers) will normally need to be able to compute this property as part of symbol resolution, and it would be inefficient to materialize every module just to compute it. See: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160509/356401.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160516/356738.html for earlier discussion. Part of the fix for PR27553. Differential Revision: http://reviews.llvm.org/D20348 llvm-svn: 272709
2016-06-15 05:01:22 +08:00
define linkonce_odr void @f4() local_unnamed_addr {
Add a small test showing when a linkonce_odr symbol can be hidden. llvm-svn: 214311
2014-07-30 23:31:21 +08:00
ret void
}
Restore "Resolution-based LTO API." This restores commit r278330, with fixes for a few bot failures: - Fix a late change I had made to the save temps output file that I missed due to existing files sitting on my disk - Fix a bunch of Windows bot failures with "ambiguous call to overloaded function" due to confusion between llvm::make_unique vs std::make_unique (preface the new make_unique calls with "llvm::") - Attempt to fix a modules bot failure by adding a missing include to LTO/Config.h. Original change: Resolution-based LTO API. Summary: This introduces a resolution-based LTO API. The main advantage of this API over existing APIs is that it allows the linker to supply a resolution for each symbol in each object, rather than the combined object as a whole. This will become increasingly important for use cases such as ThinLTO which require us to process symbol resolutions in a more complicated way than just adjusting linkage. Patch by Peter Collingbourne. Reviewers: rafael, tejohnson, mehdi_amini Subscribers: lhames, tejohnson, mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D20268 llvm-svn: 278338
2016-08-11 22:58:12 +08:00
; CHECK-DAG: define weak_odr void @f5()
; OPT-DAG: define weak_odr void @f5()
Add a small test showing when a linkonce_odr symbol can be hidden. llvm-svn: 214311
2014-07-30 23:31:21 +08:00
define linkonce_odr void @f5() {
ret void
}
IR: Introduce local_unnamed_addr attribute. If a local_unnamed_addr attribute is attached to a global, the address is known to be insignificant within the module. It is distinct from the existing unnamed_addr attribute in that it only describes a local property of the module rather than a global property of the symbol. This attribute is intended to be used by the code generator and LTO to allow the linker to decide whether the global needs to be in the symbol table. It is possible to exclude a global from the symbol table if three things are true: - This attribute is present on every instance of the global (which means that the normal rule that the global must have a unique address can be broken without being observable by the program by performing comparisons against the global's address) - The global has linkonce_odr linkage (which means that each linkage unit must have its own copy of the global if it requires one, and the copy in each linkage unit must be the same) - It is a constant or a function (which means that the program cannot observe that the unique-address rule has been broken by writing to the global) Although this attribute could in principle be computed from the module contents, LTO clients (i.e. linkers) will normally need to be able to compute this property as part of symbol resolution, and it would be inefficient to materialize every module just to compute it. See: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160509/356401.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160516/356738.html for earlier discussion. Part of the fix for PR27553. Differential Revision: http://reviews.llvm.org/D20348 llvm-svn: 272709
2016-06-15 05:01:22 +08:00
@g9 = global void()* @f5
Add a small test showing when a linkonce_odr symbol can be hidden. llvm-svn: 214311
2014-07-30 23:31:21 +08:00
Don't depend on the order the IR is copied. llvm-svn: 254257
2015-11-29 23:22:49 +08:00
; CHECK-DAG: define internal void @f6() unnamed_addr
; OPT-DAG: define internal void @f6() unnamed_addr
Add a small test showing when a linkonce_odr symbol can be hidden. llvm-svn: 214311
2014-07-30 23:31:21 +08:00
define linkonce_odr void @f6() unnamed_addr {
ret void
}
IR: Introduce local_unnamed_addr attribute. If a local_unnamed_addr attribute is attached to a global, the address is known to be insignificant within the module. It is distinct from the existing unnamed_addr attribute in that it only describes a local property of the module rather than a global property of the symbol. This attribute is intended to be used by the code generator and LTO to allow the linker to decide whether the global needs to be in the symbol table. It is possible to exclude a global from the symbol table if three things are true: - This attribute is present on every instance of the global (which means that the normal rule that the global must have a unique address can be broken without being observable by the program by performing comparisons against the global's address) - The global has linkonce_odr linkage (which means that each linkage unit must have its own copy of the global if it requires one, and the copy in each linkage unit must be the same) - It is a constant or a function (which means that the program cannot observe that the unique-address rule has been broken by writing to the global) Although this attribute could in principle be computed from the module contents, LTO clients (i.e. linkers) will normally need to be able to compute this property as part of symbol resolution, and it would be inefficient to materialize every module just to compute it. See: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160509/356401.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160516/356738.html for earlier discussion. Part of the fix for PR27553. Differential Revision: http://reviews.llvm.org/D20348 llvm-svn: 272709
2016-06-15 05:01:22 +08:00
@g10 = global void()* @f6
Fix using -plugin-opt=apiflie when also using -plugin-opt=emit-llvm. llvm-svn: 215378
2014-08-12 03:06:54 +08:00
Fix handling of extern_weak. This was broken by r225983. llvm-svn: 226026
2015-01-15 03:43:32 +08:00
define i32* @f7() {
ret i32* @g7
}
Fix using -plugin-opt=apiflie when also using -plugin-opt=emit-llvm. llvm-svn: 215378
2014-08-12 03:06:54 +08:00
Fix linking of shared libraries. In shared libraries the plugin can see non-weak declarations that are still undefined. llvm-svn: 226031
2015-01-15 04:08:46 +08:00
define i32* @f8() {
ret i32* @g8
}
Restore "Resolution-based LTO API." This restores commit r278330, with fixes for a few bot failures: - Fix a late change I had made to the save temps output file that I missed due to existing files sitting on my disk - Fix a bunch of Windows bot failures with "ambiguous call to overloaded function" due to confusion between llvm::make_unique vs std::make_unique (preface the new make_unique calls with "llvm::") - Attempt to fix a modules bot failure by adding a missing include to LTO/Config.h. Original change: Resolution-based LTO API. Summary: This introduces a resolution-based LTO API. The main advantage of this API over existing APIs is that it allows the linker to supply a resolution for each symbol in each object, rather than the combined object as a whole. This will become increasingly important for use cases such as ThinLTO which require us to process symbol resolutions in a more complicated way than just adjusting linkage. Patch by Peter Collingbourne. Reviewers: rafael, tejohnson, mehdi_amini Subscribers: lhames, tejohnson, mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D20268 llvm-svn: 278338
2016-08-11 22:58:12 +08:00
; RES: .o,f1,pl{{$}}
; RES: .o,f2,pl{{$}}
; RES: .o,f3,px{{$}}
; RES: .o,f4,p{{$}}
; RES: .o,f5,px{{$}}
; RES: .o,f6,p{{$}}
; RES: .o,f7,px{{$}}
; RES: .o,f8,px{{$}}
; RES: .o,g1,px{{$}}
; RES: .o,g2,p{{$}}
; RES: .o,g3,p{{$}}
; RES: .o,g4,px{{$}}
; RES: .o,g5,px{{$}}
; RES: .o,g6,p{{$}}
; RES: .o,g7,{{$}}
; RES: .o,g8,{{$}}
; RES: .o,g9,px{{$}}
; RES: .o,g10,px{{$}}