llvm-mirror/test/Assembler/unnamed-addr.ll

; RUN: llvm-as < %s | llvm-dis | FileCheck %s

%struct.foobar = type { i32 }

@bar.d = internal unnamed_addr constant %struct.foobar zeroinitializer, align 4
@foo.d = internal constant %struct.foobar zeroinitializer, align 4

define i32 @main() unnamed_addr nounwind ssp {
entry:
  %call2 = tail call i32 @zed(%struct.foobar* @foo.d, %struct.foobar* @bar.d) nounwind
  ret i32 0
}

declare i32 @zed(%struct.foobar*, %struct.foobar*)

; CHECK: @bar.d = internal unnamed_addr constant %struct.foobar zeroinitializer, align 4
; CHECK: @foo.d = internal constant %struct.foobar zeroinitializer, align 4
; CHECK: define i32 @main() unnamed_addr #0 {

; CHECK: attributes #0 = { nounwind ssp }
First step in fixing PR8927: Add a unnamed_addr bit to global variables and functions. This will be used to indicate that the address is not significant and therefore the constant or function can be merged with others. If an optimization pass can show that an address is not used, it can set this. Examples of things that can have this set by the FE are globals created to hold string literals and C++ constructors. Adding unnamed_addr to a non-const global should have no effect unless an optimization can transform that global into a constant. Aliases are not allowed to have unnamed_addr since I couldn't figure out any use for it. llvm-svn: 123063 2011-01-08 17:42:36 +01:00			`; RUN: llvm-as < %s \| llvm-dis \| FileCheck %s`

			`%struct.foobar = type { i32 }`

			`@bar.d = internal unnamed_addr constant %struct.foobar zeroinitializer, align 4`
			`@foo.d = internal constant %struct.foobar zeroinitializer, align 4`

Move unnamed_addr after the function arguments on Sabre's request. llvm-svn: 124209 2011-01-25 20:09:56 +01:00			`define i32 @main() unnamed_addr nounwind ssp {`
First step in fixing PR8927: Add a unnamed_addr bit to global variables and functions. This will be used to indicate that the address is not significant and therefore the constant or function can be merged with others. If an optimization pass can show that an address is not used, it can set this. Examples of things that can have this set by the FE are globals created to hold string literals and C++ constructors. Adding unnamed_addr to a non-const global should have no effect unless an optimization can transform that global into a constant. Aliases are not allowed to have unnamed_addr since I couldn't figure out any use for it. llvm-svn: 123063 2011-01-08 17:42:36 +01:00			`entry:`
			`%call2 = tail call i32 @zed(%struct.foobar* @foo.d, %struct.foobar* @bar.d) nounwind`
			`ret i32 0`
			`}`

			`declare i32 @zed(%struct.foobar, %struct.foobar)`

			`; CHECK: @bar.d = internal unnamed_addr constant %struct.foobar zeroinitializer, align 4`
			`; CHECK: @foo.d = internal constant %struct.foobar zeroinitializer, align 4`
Modify the LLVM assembly output so that it uses references to represent function attributes. This makes the LLVM assembly look better. E.g.: define void @foo() #0 { ret void } attributes #0 = { nounwind noinline ssp } llvm-svn: 175605 2013-02-20 08:21:42 +01:00			`; CHECK: define i32 @main() unnamed_addr #0 {`

			`; CHECK: attributes #0 = { nounwind ssp }`