llvm-mirror/test/Bitcode/cmpxchg.3.6.ll

; RUN: llvm-dis < %s.bc | FileCheck %s

define void @f2(i32* %x, i32 %y.orig, i32 %z) {
entry:
  br label %a
b:
  cmpxchg i32* %x, i32 %y, i32 %z acquire acquire
; CHECK: cmpxchg i32* %x, i32 %y, i32 %z acquire acquire
  ret void
a:
  %y = add i32 %y.orig, 1
  br label %a
}
[opaque pointer type] Encode the pointee type in the bitcode for 'cmpxchg' As a space optimization, this instruction would just encode the pointer type of the first operand and use the knowledge that the second and third operands would be of the pointee type of the first. When typed pointers go away, this assumption will no longer be available - so encode the type of the second operand explicitly and rely on that for the third. Test case added to demonstrate the backwards compatibility concern, which only comes up when the definition of the second operand comes after the use (hence the weird basic block sequence) - at which point the type needs to be explicitly encoded in the bitcode and the record length changes to accommodate this. llvm-svn: 235966 2015-04-28 06:30:29 +02:00			`; RUN: llvm-dis < %s.bc \| FileCheck %s`

			`define void @f2(i32* %x, i32 %y.orig, i32 %z) {`
			`entry:`
			`br label %a`
			`b:`
			`cmpxchg i32* %x, i32 %y, i32 %z acquire acquire`
			`; CHECK: cmpxchg i32* %x, i32 %y, i32 %z acquire acquire`
			`ret void`
			`a:`
			`%y = add i32 %y.orig, 1`
			`br label %a`
			`}`