llvm-project/llvm/test/CodeGen/X86/membarrier.ll

; RUN: llc < %s -mtriple=x86_64-- -mattr=-sse -O0
; PR9675

define i32 @t() {
entry:
  %i = alloca i32, align 4
  store i32 1, i32* %i, align 4
  fence seq_cst
  %0 = atomicrmw sub i32* %i, i32 1 monotonic
  fence seq_cst
  ret i32 0
}
X86: Do not use llc -march in tests. `llc -march` is problematic because it only switches the target architecture, but leaves the operating system unchanged. This occasionally leads to indeterministic tests because the OS from LLVM_DEFAULT_TARGET_TRIPLE is used. However we can simply always use `llc -mtriple` instead. This changes all the tests to do this to avoid people using -march when they copy and paste parts of tests. See also the discussion in https://reviews.llvm.org/D35287 llvm-svn: 309774 2017-08-02 08:28:10 +08:00			`; RUN: llc < %s -mtriple=x86_64-- -mattr=-sse -O0`
Go ahead and emit the barrier on x86-64 even without sse2. The processor supports it just fine. Fixes PR9675 and rdar://9740801 llvm-svn: 134664 2011-07-08 08:04:56 +08:00			`; PR9675`

			`define i32 @t() {`
			`entry:`
			`%i = alloca i32, align 4`
			`store i32 1, i32* %i, align 4`
Last batch of test conversions to new atomic instructions. llvm-svn: 140585 2011-09-27 08:17:29 +08:00			`fence seq_cst`
			`%0 = atomicrmw sub i32* %i, i32 1 monotonic`
			`fence seq_cst`
Go ahead and emit the barrier on x86-64 even without sse2. The processor supports it just fine. Fixes PR9675 and rdar://9740801 llvm-svn: 134664 2011-07-08 08:04:56 +08:00			`ret i32 0`
			`}`