llvm-project/clang/test/CodeGen/2008-03-05-syncPtr.c
Eli Friedman e9f8113ec4 Switch clang over to using fence/atomicrmw/cmpxchg instead of the intrinsics (which will go away). LLVM CodeGen does almost exactly the same thing with these and the old intrinsics, so I'm reasonably confident this will not break anything.
There are still a few issues which need to be resolved with code generation for atomic load and store, so I'm not converting the places which need those for now.

I'm not entirely sure what to do about __builtin_llvm_memory_barrier: the fence instruction doesn't expose all the possibilities which can be expressed by __builtin_llvm_memory_barrier.  I would appreciate hearing from anyone who is using this intrinsic.

llvm-svn: 139216
2011-09-07 01:41:24 +00:00

41 lines
816 B
C

// RUN: %clang_cc1 %s -emit-llvm -o - | FileCheck %s
int* foo(int** a, int* b, int* c) {
return __sync_val_compare_and_swap (a, b, c);
}
// CHECK: define i32* @foo
// CHECK: cmpxchg
int foo2(int** a, int* b, int* c) {
return __sync_bool_compare_and_swap (a, b, c);
}
// CHECK: define i32 @foo2
// CHECK: cmpxchg
int* foo3(int** a, int b) {
return __sync_fetch_and_add (a, b);
}
// CHECK: define i32* @foo3
// CHECK: atomicrmw add
int* foo4(int** a, int b) {
return __sync_fetch_and_sub (a, b);
}
// CHECK: define i32* @foo4
// CHECK: atomicrmw sub
int* foo5(int** a, int* b) {
return __sync_lock_test_and_set (a, b);
}
// CHECK: define i32* @foo5
// CHECK: atomicrmw xchg
int* foo6(int** a, int*** b) {
return __sync_lock_test_and_set (a, b);
}
// CHECK: define i32* @foo6
// CHECK: atomicrmw xchg