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

129 lines
3.9 KiB
LLVM
Raw Normal View History

Restore part of "[ThinLTO] Prevent exporting of locals used/defined in module level asm" This restores the part of r286297 that didn't require adding a dependency from the Analysis to Object library. There are two parts to the original fix, and this will address the handling for the case where locals are used in module level asm. The part that requires functionality in libObject handles local defs in module level asm, and was reverted because our downstream build of clang builds lib/Bitcode into a single library, and this new dependency introduced a cycle there. I am trying to get that fixed (see D26502), so for now that change isn't being restored llvm-svn: 286475
2016-11-10 17:57:32 +01:00
; Test to ensure that uses and defs in module level asm are handled
; appropriately. Specifically, we should conservatively block importing
; of any references to these values, as they can't be renamed.
; RUN: opt -module-summary %s -o %t1.bc
; RUN: opt -module-summary %p/Inputs/module_asm2.ll -o %t2.bc
[ThinLTO] Fix "||" vs "|" mixup. The effect of the bug was that we would incorrectly create summaries for global and weak values defined in module asm (since we were essentially testing for bit 1 which is SF_Undefined, and the RecordStreamer ignores local undefined references). This would have resulted in conservatively disabling importing of anything referencing globals and weaks defined in module asm. Added these cases to the test which now fails without this bug fix. Fixes PR31459. llvm-svn: 290610
2016-12-27 18:45:09 +01:00
; RUN: llvm-lto -thinlto-action=run -exported-symbol=main -exported-symbol=func1 -exported-symbol=func2 -exported-symbol=func3 -exported-symbol=callglobalfunc -exported-symbol=callweakfunc %t1.bc %t2.bc
; RUN: llvm-nm %t1.bc.thinlto.o | FileCheck %s --check-prefix=NM0
; RUN: llvm-nm %t2.bc.thinlto.o | FileCheck %s --check-prefix=NM1
Restore part of "[ThinLTO] Prevent exporting of locals used/defined in module level asm" This restores the part of r286297 that didn't require adding a dependency from the Analysis to Object library. There are two parts to the original fix, and this will address the handling for the case where locals are used in module level asm. The part that requires functionality in libObject handles local defs in module level asm, and was reverted because our downstream build of clang builds lib/Bitcode into a single library, and this new dependency introduced a cycle there. I am trying to get that fixed (see D26502), so for now that change isn't being restored llvm-svn: 286475
2016-11-10 17:57:32 +01:00
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-11 20:12:00 +02:00
; RUN: llvm-lto2 run %t1.bc %t2.bc -o %t.o -save-temps \
Restore part of "[ThinLTO] Prevent exporting of locals used/defined in module level asm" This restores the part of r286297 that didn't require adding a dependency from the Analysis to Object library. There are two parts to the original fix, and this will address the handling for the case where locals are used in module level asm. The part that requires functionality in libObject handles local defs in module level asm, and was reverted because our downstream build of clang builds lib/Bitcode into a single library, and this new dependency introduced a cycle there. I am trying to get that fixed (see D26502), so for now that change isn't being restored llvm-svn: 286475
2016-11-10 17:57:32 +01:00
; RUN: -r=%t1.bc,foo,plx \
[ThinLTO] Fix "||" vs "|" mixup. The effect of the bug was that we would incorrectly create summaries for global and weak values defined in module asm (since we were essentially testing for bit 1 which is SF_Undefined, and the RecordStreamer ignores local undefined references). This would have resulted in conservatively disabling importing of anything referencing globals and weaks defined in module asm. Added these cases to the test which now fails without this bug fix. Fixes PR31459. llvm-svn: 290610
2016-12-27 18:45:09 +01:00
; RUN: -r=%t1.bc,globalfunc,plx \
[LLVMgold] Don't set undefined symbol as prevailing Differential revision: https://reviews.llvm.org/D41113 llvm-svn: 320794
2017-12-15 10:18:21 +01:00
; RUN: -r=%t1.bc,globalfunc,lx \
[ThinLTO] Fix "||" vs "|" mixup. The effect of the bug was that we would incorrectly create summaries for global and weak values defined in module asm (since we were essentially testing for bit 1 which is SF_Undefined, and the RecordStreamer ignores local undefined references). This would have resulted in conservatively disabling importing of anything referencing globals and weaks defined in module asm. Added these cases to the test which now fails without this bug fix. Fixes PR31459. llvm-svn: 290610
2016-12-27 18:45:09 +01:00
; RUN: -r=%t1.bc,weakfunc,plx \
[LLVMgold] Don't set undefined symbol as prevailing Differential revision: https://reviews.llvm.org/D41113 llvm-svn: 320794
2017-12-15 10:18:21 +01:00
; RUN: -r=%t1.bc,weakfunc,lx \
Restore part of "[ThinLTO] Prevent exporting of locals used/defined in module level asm" This restores the part of r286297 that didn't require adding a dependency from the Analysis to Object library. There are two parts to the original fix, and this will address the handling for the case where locals are used in module level asm. The part that requires functionality in libObject handles local defs in module level asm, and was reverted because our downstream build of clang builds lib/Bitcode into a single library, and this new dependency introduced a cycle there. I am trying to get that fixed (see D26502), so for now that change isn't being restored llvm-svn: 286475
2016-11-10 17:57:32 +01:00
; RUN: -r=%t1.bc,b,pl \
; RUN: -r=%t1.bc,x,pl \
; RUN: -r=%t1.bc,func1,pl \
; RUN: -r=%t1.bc,func2,pl \
; RUN: -r=%t1.bc,func3,pl \
[ThinLTO] Fix "||" vs "|" mixup. The effect of the bug was that we would incorrectly create summaries for global and weak values defined in module asm (since we were essentially testing for bit 1 which is SF_Undefined, and the RecordStreamer ignores local undefined references). This would have resulted in conservatively disabling importing of anything referencing globals and weaks defined in module asm. Added these cases to the test which now fails without this bug fix. Fixes PR31459. llvm-svn: 290610
2016-12-27 18:45:09 +01:00
; RUN: -r=%t1.bc,callglobalfunc,plx \
; RUN: -r=%t1.bc,callweakfunc,plx \
Restore part of "[ThinLTO] Prevent exporting of locals used/defined in module level asm" This restores the part of r286297 that didn't require adding a dependency from the Analysis to Object library. There are two parts to the original fix, and this will address the handling for the case where locals are used in module level asm. The part that requires functionality in libObject handles local defs in module level asm, and was reverted because our downstream build of clang builds lib/Bitcode into a single library, and this new dependency introduced a cycle there. I am trying to get that fixed (see D26502), so for now that change isn't being restored llvm-svn: 286475
2016-11-10 17:57:32 +01:00
; RUN: -r=%t2.bc,main,plx \
; RUN: -r=%t2.bc,func1,l \
; RUN: -r=%t2.bc,func2,l \
[ThinLTO] Fix "||" vs "|" mixup. The effect of the bug was that we would incorrectly create summaries for global and weak values defined in module asm (since we were essentially testing for bit 1 which is SF_Undefined, and the RecordStreamer ignores local undefined references). This would have resulted in conservatively disabling importing of anything referencing globals and weaks defined in module asm. Added these cases to the test which now fails without this bug fix. Fixes PR31459. llvm-svn: 290610
2016-12-27 18:45:09 +01:00
; RUN: -r=%t2.bc,func3,l \
; RUN: -r=%t2.bc,callglobalfunc,l \
; RUN: -r=%t2.bc,callweakfunc,l
[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 03:10:00 +01:00
; RUN: llvm-nm %t.o.1 | FileCheck %s --check-prefix=NM0
; RUN: llvm-nm %t.o.2 | FileCheck %s --check-prefix=NM1
Restore part of "[ThinLTO] Prevent exporting of locals used/defined in module level asm" This restores the part of r286297 that didn't require adding a dependency from the Analysis to Object library. There are two parts to the original fix, and this will address the handling for the case where locals are used in module level asm. The part that requires functionality in libObject handles local defs in module level asm, and was reverted because our downstream build of clang builds lib/Bitcode into a single library, and this new dependency introduced a cycle there. I am trying to get that fixed (see D26502), so for now that change isn't being restored llvm-svn: 286475
2016-11-10 17:57:32 +01:00
; Check that local values b and x, which are referenced on
; llvm.used and llvm.compiler.used, respectively, are not promoted.
; Similarly, foo which is defined in module level asm should not be
[ThinLTO] Fix "||" vs "|" mixup. The effect of the bug was that we would incorrectly create summaries for global and weak values defined in module asm (since we were essentially testing for bit 1 which is SF_Undefined, and the RecordStreamer ignores local undefined references). This would have resulted in conservatively disabling importing of anything referencing globals and weaks defined in module asm. Added these cases to the test which now fails without this bug fix. Fixes PR31459. llvm-svn: 290610
2016-12-27 18:45:09 +01:00
; promoted.
Restore part of "[ThinLTO] Prevent exporting of locals used/defined in module level asm" This restores the part of r286297 that didn't require adding a dependency from the Analysis to Object library. There are two parts to the original fix, and this will address the handling for the case where locals are used in module level asm. The part that requires functionality in libObject handles local defs in module level asm, and was reverted because our downstream build of clang builds lib/Bitcode into a single library, and this new dependency introduced a cycle there. I am trying to get that fixed (see D26502), so for now that change isn't being restored llvm-svn: 286475
2016-11-10 17:57:32 +01:00
; NM0-DAG: d b
; NM0-DAG: d x
; NM0-DAG: t foo
; NM0-DAG: T func1
; NM0-DAG: T func2
; NM0-DAG: T func3
[ThinLTO] Fix "||" vs "|" mixup. The effect of the bug was that we would incorrectly create summaries for global and weak values defined in module asm (since we were essentially testing for bit 1 which is SF_Undefined, and the RecordStreamer ignores local undefined references). This would have resulted in conservatively disabling importing of anything referencing globals and weaks defined in module asm. Added these cases to the test which now fails without this bug fix. Fixes PR31459. llvm-svn: 290610
2016-12-27 18:45:09 +01:00
; NM0-DAG: T callglobalfunc
; NM0-DAG: T callweakfunc
; NM0-DAG: T globalfunc
; NM0-DAG: W weakfunc
Restore part of "[ThinLTO] Prevent exporting of locals used/defined in module level asm" This restores the part of r286297 that didn't require adding a dependency from the Analysis to Object library. There are two parts to the original fix, and this will address the handling for the case where locals are used in module level asm. The part that requires functionality in libObject handles local defs in module level asm, and was reverted because our downstream build of clang builds lib/Bitcode into a single library, and this new dependency introduced a cycle there. I am trying to get that fixed (see D26502), so for now that change isn't being restored llvm-svn: 286475
2016-11-10 17:57:32 +01:00
Restore "[ThinLTO] Prevent exporting of locals used/defined in module level asm" This restores the rest of r286297 (part was restored in r286475). Specifically, it restores the part requiring adding a dependency from the Analysis to Object library (downstream use changed to correctly model split BitReader vs BitWriter libraries). Original description of this part of patch follows: Module level asm may also contain defs of values. We need to prevent export of any refs to local values defined in module level asm (e.g. a ref in normal IR), since that also requires renaming/promotion of the local. To do that, the summary index builder looks at all values in the module level asm string that are not marked Weak or Global, which is exactly the set of locals that are defined. A summary is created for each of these local defs and flagged as NoRename. This required adding handling to the BitcodeWriter to look at GV declarations to see if they have a summary (rather than skipping them all). Finally, added an assert to IRObjectFile::CollectAsmUndefinedRefs to ensure that an MCAsmParser is available, otherwise the module asm parse would silently fail. Initialized the asm parser in the opt tool for use in testing this fix. Fixes PR30610. llvm-svn: 286844
2016-11-14 18:12:32 +01:00
; Ensure that foo, b and x are likewise not exported (imported as refs
Restore part of "[ThinLTO] Prevent exporting of locals used/defined in module level asm" This restores the part of r286297 that didn't require adding a dependency from the Analysis to Object library. There are two parts to the original fix, and this will address the handling for the case where locals are used in module level asm. The part that requires functionality in libObject handles local defs in module level asm, and was reverted because our downstream build of clang builds lib/Bitcode into a single library, and this new dependency introduced a cycle there. I am trying to get that fixed (see D26502), so for now that change isn't being restored llvm-svn: 286475
2016-11-10 17:57:32 +01:00
; into the other module), since they can't be promoted. Additionally,
; referencing functions func2 and func3 should not have been
[ThinLTO] Fix "||" vs "|" mixup. The effect of the bug was that we would incorrectly create summaries for global and weak values defined in module asm (since we were essentially testing for bit 1 which is SF_Undefined, and the RecordStreamer ignores local undefined references). This would have resulted in conservatively disabling importing of anything referencing globals and weaks defined in module asm. Added these cases to the test which now fails without this bug fix. Fixes PR31459. llvm-svn: 290610
2016-12-27 18:45:09 +01:00
; imported. However, we should have been able to import callglobalfunc
; and callweakfunc (leaving undefined symbols globalfunc and weakfunc)
; since globalfunc and weakfunc were defined but not local in module asm.
Restore "[ThinLTO] Prevent exporting of locals used/defined in module level asm" This restores the rest of r286297 (part was restored in r286475). Specifically, it restores the part requiring adding a dependency from the Analysis to Object library (downstream use changed to correctly model split BitReader vs BitWriter libraries). Original description of this part of patch follows: Module level asm may also contain defs of values. We need to prevent export of any refs to local values defined in module level asm (e.g. a ref in normal IR), since that also requires renaming/promotion of the local. To do that, the summary index builder looks at all values in the module level asm string that are not marked Weak or Global, which is exactly the set of locals that are defined. A summary is created for each of these local defs and flagged as NoRename. This required adding handling to the BitcodeWriter to look at GV declarations to see if they have a summary (rather than skipping them all). Finally, added an assert to IRObjectFile::CollectAsmUndefinedRefs to ensure that an MCAsmParser is available, otherwise the module asm parse would silently fail. Initialized the asm parser in the opt tool for use in testing this fix. Fixes PR30610. llvm-svn: 286844
2016-11-14 18:12:32 +01:00
; NM1-NOT: foo
Restore part of "[ThinLTO] Prevent exporting of locals used/defined in module level asm" This restores the part of r286297 that didn't require adding a dependency from the Analysis to Object library. There are two parts to the original fix, and this will address the handling for the case where locals are used in module level asm. The part that requires functionality in libObject handles local defs in module level asm, and was reverted because our downstream build of clang builds lib/Bitcode into a single library, and this new dependency introduced a cycle there. I am trying to get that fixed (see D26502), so for now that change isn't being restored llvm-svn: 286475
2016-11-10 17:57:32 +01:00
; NM1-NOT: b
; NM1-NOT: x
Restore "[ThinLTO] Prevent exporting of locals used/defined in module level asm" This restores the rest of r286297 (part was restored in r286475). Specifically, it restores the part requiring adding a dependency from the Analysis to Object library (downstream use changed to correctly model split BitReader vs BitWriter libraries). Original description of this part of patch follows: Module level asm may also contain defs of values. We need to prevent export of any refs to local values defined in module level asm (e.g. a ref in normal IR), since that also requires renaming/promotion of the local. To do that, the summary index builder looks at all values in the module level asm string that are not marked Weak or Global, which is exactly the set of locals that are defined. A summary is created for each of these local defs and flagged as NoRename. This required adding handling to the BitcodeWriter to look at GV declarations to see if they have a summary (rather than skipping them all). Finally, added an assert to IRObjectFile::CollectAsmUndefinedRefs to ensure that an MCAsmParser is available, otherwise the module asm parse would silently fail. Initialized the asm parser in the opt tool for use in testing this fix. Fixes PR30610. llvm-svn: 286844
2016-11-14 18:12:32 +01:00
; NM1-DAG: U func1
Restore part of "[ThinLTO] Prevent exporting of locals used/defined in module level asm" This restores the part of r286297 that didn't require adding a dependency from the Analysis to Object library. There are two parts to the original fix, and this will address the handling for the case where locals are used in module level asm. The part that requires functionality in libObject handles local defs in module level asm, and was reverted because our downstream build of clang builds lib/Bitcode into a single library, and this new dependency introduced a cycle there. I am trying to get that fixed (see D26502), so for now that change isn't being restored llvm-svn: 286475
2016-11-10 17:57:32 +01:00
; NM1-DAG: U func2
; NM1-DAG: U func3
[ThinLTO] Fix "||" vs "|" mixup. The effect of the bug was that we would incorrectly create summaries for global and weak values defined in module asm (since we were essentially testing for bit 1 which is SF_Undefined, and the RecordStreamer ignores local undefined references). This would have resulted in conservatively disabling importing of anything referencing globals and weaks defined in module asm. Added these cases to the test which now fails without this bug fix. Fixes PR31459. llvm-svn: 290610
2016-12-27 18:45:09 +01:00
; NM1-DAG: U globalfunc
; NM1-DAG: U weakfunc
Restore part of "[ThinLTO] Prevent exporting of locals used/defined in module level asm" This restores the part of r286297 that didn't require adding a dependency from the Analysis to Object library. There are two parts to the original fix, and this will address the handling for the case where locals are used in module level asm. The part that requires functionality in libObject handles local defs in module level asm, and was reverted because our downstream build of clang builds lib/Bitcode into a single library, and this new dependency introduced a cycle there. I am trying to get that fixed (see D26502), so for now that change isn't being restored llvm-svn: 286475
2016-11-10 17:57:32 +01:00
; NM1-DAG: T main
Restore "[ThinLTO] Prevent exporting of locals used/defined in module level asm" This restores the rest of r286297 (part was restored in r286475). Specifically, it restores the part requiring adding a dependency from the Analysis to Object library (downstream use changed to correctly model split BitReader vs BitWriter libraries). Original description of this part of patch follows: Module level asm may also contain defs of values. We need to prevent export of any refs to local values defined in module level asm (e.g. a ref in normal IR), since that also requires renaming/promotion of the local. To do that, the summary index builder looks at all values in the module level asm string that are not marked Weak or Global, which is exactly the set of locals that are defined. A summary is created for each of these local defs and flagged as NoRename. This required adding handling to the BitcodeWriter to look at GV declarations to see if they have a summary (rather than skipping them all). Finally, added an assert to IRObjectFile::CollectAsmUndefinedRefs to ensure that an MCAsmParser is available, otherwise the module asm parse would silently fail. Initialized the asm parser in the opt tool for use in testing this fix. Fixes PR30610. llvm-svn: 286844
2016-11-14 18:12:32 +01:00
; NM1-NOT: foo
Restore part of "[ThinLTO] Prevent exporting of locals used/defined in module level asm" This restores the part of r286297 that didn't require adding a dependency from the Analysis to Object library. There are two parts to the original fix, and this will address the handling for the case where locals are used in module level asm. The part that requires functionality in libObject handles local defs in module level asm, and was reverted because our downstream build of clang builds lib/Bitcode into a single library, and this new dependency introduced a cycle there. I am trying to get that fixed (see D26502), so for now that change isn't being restored llvm-svn: 286475
2016-11-10 17:57:32 +01:00
; NM1-NOT: b
; NM1-NOT: x
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:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
Restore part of "[ThinLTO] Prevent exporting of locals used/defined in module level asm" This restores the part of r286297 that didn't require adding a dependency from the Analysis to Object library. There are two parts to the original fix, and this will address the handling for the case where locals are used in module level asm. The part that requires functionality in libObject handles local defs in module level asm, and was reverted because our downstream build of clang builds lib/Bitcode into a single library, and this new dependency introduced a cycle there. I am trying to get that fixed (see D26502), so for now that change isn't being restored llvm-svn: 286475
2016-11-10 17:57:32 +01:00
target triple = "x86_64-unknown-linux-gnu"
@b = internal global i32 1, align 4
@x = internal global i32 1, align 4
@llvm.compiler.used = appending global [1 x i8*] [i8* bitcast (i32* @b to i8*)], section "llvm.metadata"
@llvm.used = appending global [1 x i8*] [i8* bitcast (i32* @x to i8*)], section "llvm.metadata"
module asm "\09.text"
module asm "\09.type\09foo,@function"
module asm "foo:"
module asm "\09movl b, %eax"
module asm "\09movl x, %edx"
module asm "\09ret "
module asm "\09.size\09foo, .-foo"
module asm ""
[ThinLTO] Fix "||" vs "|" mixup. The effect of the bug was that we would incorrectly create summaries for global and weak values defined in module asm (since we were essentially testing for bit 1 which is SF_Undefined, and the RecordStreamer ignores local undefined references). This would have resulted in conservatively disabling importing of anything referencing globals and weaks defined in module asm. Added these cases to the test which now fails without this bug fix. Fixes PR31459. llvm-svn: 290610
2016-12-27 18:45:09 +01:00
module asm "\09.globl\09globalfunc"
module asm "\09.type\09globalfunc,@function"
module asm "globalfunc:"
module asm "\09movl b, %eax"
module asm "\09movl x, %edx"
module asm "\09ret "
module asm "\09.size\09globalfunc, .-globalfunc"
module asm ""
module asm "\09.weak\09weakfunc"
module asm "\09.type\09weakfunc,@function"
module asm "weakfunc:"
module asm "\09movl b, %eax"
module asm "\09movl x, %edx"
module asm "\09ret "
module asm "\09.size\09weakfunc, .-weakfunc"
module asm ""
Restore part of "[ThinLTO] Prevent exporting of locals used/defined in module level asm" This restores the part of r286297 that didn't require adding a dependency from the Analysis to Object library. There are two parts to the original fix, and this will address the handling for the case where locals are used in module level asm. The part that requires functionality in libObject handles local defs in module level asm, and was reverted because our downstream build of clang builds lib/Bitcode into a single library, and this new dependency introduced a cycle there. I am trying to get that fixed (see D26502), so for now that change isn't being restored llvm-svn: 286475
2016-11-10 17:57:32 +01:00
declare i16 @foo() #0
[ThinLTO] Fix "||" vs "|" mixup. The effect of the bug was that we would incorrectly create summaries for global and weak values defined in module asm (since we were essentially testing for bit 1 which is SF_Undefined, and the RecordStreamer ignores local undefined references). This would have resulted in conservatively disabling importing of anything referencing globals and weaks defined in module asm. Added these cases to the test which now fails without this bug fix. Fixes PR31459. llvm-svn: 290610
2016-12-27 18:45:09 +01:00
declare i16 @globalfunc() #0
declare i16 @weakfunc() #0
Restore part of "[ThinLTO] Prevent exporting of locals used/defined in module level asm" This restores the part of r286297 that didn't require adding a dependency from the Analysis to Object library. There are two parts to the original fix, and this will address the handling for the case where locals are used in module level asm. The part that requires functionality in libObject handles local defs in module level asm, and was reverted because our downstream build of clang builds lib/Bitcode into a single library, and this new dependency introduced a cycle there. I am trying to get that fixed (see D26502), so for now that change isn't being restored llvm-svn: 286475
2016-11-10 17:57:32 +01:00
define i32 @func1() #1 {
call i16 @foo()
ret i32 1
}
define i32 @func2() #1 {
%1 = load i32, i32* @b, align 4
ret i32 %1
}
define i32 @func3() #1 {
%1 = load i32, i32* @x, align 4
ret i32 %1
}
[ThinLTO] Fix "||" vs "|" mixup. The effect of the bug was that we would incorrectly create summaries for global and weak values defined in module asm (since we were essentially testing for bit 1 which is SF_Undefined, and the RecordStreamer ignores local undefined references). This would have resulted in conservatively disabling importing of anything referencing globals and weaks defined in module asm. Added these cases to the test which now fails without this bug fix. Fixes PR31459. llvm-svn: 290610
2016-12-27 18:45:09 +01:00
define i32 @callglobalfunc() #1 {
call i16 @globalfunc()
ret i32 1
}
define i32 @callweakfunc() #1 {
call i16 @weakfunc()
ret i32 1
}
Reference in New Issue Copy Permalink