maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/CodeGen/PowerPC/private.ll

29 lines
597 B
LLVM
Raw Normal View History

Add the private linkage. llvm-svn: 62279
2009-01-16 04:18:42 +08:00
; Test to make sure that the 'private' is used correctly.
;
Convert test to FileCheck. llvm-svn: 200955
2014-02-07 07:35:22 +08:00
; RUN: llc < %s -mtriple=powerpc-unknown-linux-gnu | \
; RUN: FileCheck --check-prefix=LINUX %s
;
; RUN: llc < %s -mtriple=powerpc-apple-darwin | \
; RUN: FileCheck --check-prefix=OSX %s
Add the private linkage. llvm-svn: 62279
2009-01-16 04:18:42 +08:00
Convert test to FileCheck. llvm-svn: 200955
2014-02-07 07:35:22 +08:00
; LINUX: .Lfoo:
Add back r201608, r201622, r201624 and r201625 r201608 made llvm corretly handle private globals with MachO. r201622 fixed a bug in it and r201624 and r201625 were changes for using private linkage, assuming that llvm would do the right thing. They all got reverted because r201608 introduced a crash in LTO. This patch includes a fix for that. The issue was that TargetLoweringObjectFile now has to be initialized before we can mangle names of private globals. This is trivially true during the normal codegen pipeline (the asm printer does it), but LTO has to do it manually. llvm-svn: 201700
2014-02-20 01:23:20 +08:00
; OSX: l_foo:
Change the internal interface to makeNameProper to take a bool that indicates whether the label is private or not, instead of taking prefix stuff. One effect of this is that symbols will be generated with *just* the private prefix, instead of both the private prefix *and* the user-label-prefix, but this doesn't matter as long as it is consistent. For example we'll now get "Lfoo" instead of "L_foo". These are just assembler temporary labels anyway, so they never even make it into the .o file. llvm-svn: 75607
2009-07-14 12:50:12 +08:00
define private void @foo() nounwind {
Add the private linkage. llvm-svn: 62279
2009-01-16 04:18:42 +08:00
ret void
Speculatively revert r76823 (i.e., reapply r75663 and r76805) to see if the real problem is fixed by the TableGen determinism fix. llvm-svn: 79851
2009-08-23 18:44:51 +08:00
}
Revert r75663 (and r76805), as it is causing regressions on powerpc. llvm-svn: 76823
2009-07-23 08:09:46 +08:00
Change the internal interface to makeNameProper to take a bool that indicates whether the label is private or not, instead of taking prefix stuff. One effect of this is that symbols will be generated with *just* the private prefix, instead of both the private prefix *and* the user-label-prefix, but this doesn't matter as long as it is consistent. For example we'll now get "Lfoo" instead of "L_foo". These are just assembler temporary labels anyway, so they never even make it into the .o file. llvm-svn: 75607
2009-07-14 12:50:12 +08:00
define i32 @bar() nounwind {
Convert test to FileCheck. llvm-svn: 200955
2014-02-07 07:35:22 +08:00
; LINUX: bl{{.*}}.Lfoo
Add back r201608, r201622, r201624 and r201625 r201608 made llvm corretly handle private globals with MachO. r201622 fixed a bug in it and r201624 and r201625 were changes for using private linkage, assuming that llvm would do the right thing. They all got reverted because r201608 introduced a crash in LTO. This patch includes a fix for that. The issue was that TargetLoweringObjectFile now has to be initialized before we can mangle names of private globals. This is trivially true during the normal codegen pipeline (the asm printer does it), but LTO has to do it manually. llvm-svn: 201700
2014-02-20 01:23:20 +08:00
; OSX: bl{{.*}}l_foo
Add the private linkage. llvm-svn: 62279
2009-01-16 04:18:42 +08:00
call void @foo()
Convert test to FileCheck. llvm-svn: 200955
2014-02-07 07:35:22 +08:00
; LINUX: lis{{.*}}.Lbaz
Add back r201608, r201622, r201624 and r201625 r201608 made llvm corretly handle private globals with MachO. r201622 fixed a bug in it and r201624 and r201625 were changes for using private linkage, assuming that llvm would do the right thing. They all got reverted because r201608 introduced a crash in LTO. This patch includes a fix for that. The issue was that TargetLoweringObjectFile now has to be initialized before we can mangle names of private globals. This is trivially true during the normal codegen pipeline (the asm printer does it), but LTO has to do it manually. llvm-svn: 201700
2014-02-20 01:23:20 +08:00
; OSX: lis{{.*}}l_baz
[opaque pointer type] Add textual IR support for explicit type parameter to load instruction Essentially the same as the GEP change in r230786. A similar migration script can be used to update test cases, though a few more test case improvements/changes were required this time around: (r229269-r229278) import fileinput import sys import re pat = re.compile(r"((?:=|:|^)\s*load (?:atomic )?(?:volatile )?(.*?))(| addrspace\(\d+\) *)\*($| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$)") for line in sys.stdin: sys.stdout.write(re.sub(pat, r"\1, \2\3*\4", line)) Reviewers: rafael, dexonsmith, grosser Differential Revision: http://reviews.llvm.org/D7649 llvm-svn: 230794
2015-02-28 05:17:42 +08:00
%1 = load i32, i32* @baz, align 4
Add the private linkage. llvm-svn: 62279
2009-01-16 04:18:42 +08:00
ret i32 %1
}
Convert test to FileCheck. llvm-svn: 200955
2014-02-07 07:35:22 +08:00
; LINUX: .Lbaz:
Add back r201608, r201622, r201624 and r201625 r201608 made llvm corretly handle private globals with MachO. r201622 fixed a bug in it and r201624 and r201625 were changes for using private linkage, assuming that llvm would do the right thing. They all got reverted because r201608 introduced a crash in LTO. This patch includes a fix for that. The issue was that TargetLoweringObjectFile now has to be initialized before we can mangle names of private globals. This is trivially true during the normal codegen pipeline (the asm printer does it), but LTO has to do it manually. llvm-svn: 201700
2014-02-20 01:23:20 +08:00
; OSX: l_baz:
Convert test to FileCheck. llvm-svn: 200955
2014-02-07 07:35:22 +08:00
@baz = private global i32 4