llvm-mirror/test/Verifier/atomics.ll

; RUN: not opt -verify < %s 2>&1 | FileCheck %s

; CHECK: atomic store operand must have integer, pointer, or floating point type!
; CHECK: atomic load operand must have integer, pointer, or floating point type!

define void @foo(x86_mmx* %P, x86_mmx %v) {
  store atomic x86_mmx %v, x86_mmx* %P unordered, align 8
  ret void
}

define x86_mmx @bar(x86_mmx* %P) {
  %v = load atomic x86_mmx, x86_mmx* %P unordered, align 8
  ret x86_mmx %v
}
[IR] Add support for floating pointer atomic loads and stores This patch allows atomic loads and stores of floating point to be specified in the IR and adds an adapter to allow them to be lowered via existing backend support for bitcast-to-equivalent-integer idiom. Previously, the only way to specify a atomic float operation was to bitcast the pointer to a i32, load the value as an i32, then bitcast to a float. At it's most basic, this patch simply moves this expansion step to the point we start lowering to the backend. This patch does not add canonicalization rules to convert the bitcast idioms to the appropriate atomic loads. I plan to do that in the future, but for now, let's simply add the support. I'd like to get instruction selection working through at least one backend (x86-64) without the bitcast conversion before canonicalizing into this form. Similarly, I haven't yet added the target hooks to opt out of the lowering step I added to AtomicExpand. I figured it would more sense to add those once at least one backend (x86) was ready to actually opt out. As you can see from the included tests, the generated code quality is not great. I plan on submitting some patches to fix this, but help from others along that line would be very welcome. I'm not super familiar with the backend and my ramp up time may be material. Differential Revision: http://reviews.llvm.org/D15471 llvm-svn: 255737 2015-12-16 01:49:36 +01:00			`; RUN: not opt -verify < %s 2>&1 \| FileCheck %s`

Polish atomic pointers Summary: I didn't realize that we already allowed atomic load/store of pointers, it was added in 2012 by r162146. This patch updates the documentation and tightens the verifier by using DataLayout to make sure that the stored size is byte-sized and power-of-two. DataLayout is also used for integers, and while I'm here I updated the corresponding code for cmpxchg and rmw. See the following discussion for context and upcoming changes to add floating-point and vector atomics: https://groups.google.com/forum/#!topic/llvm-dev/Nh0P_E3CRoo/discussion Reviewers: reames Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D15512 llvm-svn: 255931 2015-12-17 23:09:19 +01:00			`; CHECK: atomic store operand must have integer, pointer, or floating point type!`
			`; CHECK: atomic load operand must have integer, pointer, or floating point type!`
[IR] Add support for floating pointer atomic loads and stores This patch allows atomic loads and stores of floating point to be specified in the IR and adds an adapter to allow them to be lowered via existing backend support for bitcast-to-equivalent-integer idiom. Previously, the only way to specify a atomic float operation was to bitcast the pointer to a i32, load the value as an i32, then bitcast to a float. At it's most basic, this patch simply moves this expansion step to the point we start lowering to the backend. This patch does not add canonicalization rules to convert the bitcast idioms to the appropriate atomic loads. I plan to do that in the future, but for now, let's simply add the support. I'd like to get instruction selection working through at least one backend (x86-64) without the bitcast conversion before canonicalizing into this form. Similarly, I haven't yet added the target hooks to opt out of the lowering step I added to AtomicExpand. I figured it would more sense to add those once at least one backend (x86) was ready to actually opt out. As you can see from the included tests, the generated code quality is not great. I plan on submitting some patches to fix this, but help from others along that line would be very welcome. I'm not super familiar with the backend and my ramp up time may be material. Differential Revision: http://reviews.llvm.org/D15471 llvm-svn: 255737 2015-12-16 01:49:36 +01:00
			`define void @foo(x86_mmx* %P, x86_mmx %v) {`
			`store atomic x86_mmx %v, x86_mmx* %P unordered, align 8`
			`ret void`
			`}`

			`define x86_mmx @bar(x86_mmx* %P) {`
			`%v = load atomic x86_mmx, x86_mmx* %P unordered, align 8`
			`ret x86_mmx %v`
			`}`