maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/CodeGen/Atomics.c

294 lines
14 KiB
C
Raw Normal View History

Migrate most of the rest of test/FrontendC from llvm and migrate most of them to FileCheck. llvm-svn: 136159
2011-07-27 06:17:02 +08:00
// Test frontend handling of __sync builtins.
// Modified from a gcc testcase.
hopefully fix a bunch of ARM buildbot failures llvm-svn: 156513
2012-05-10 05:21:49 +08:00
// RUN: %clang_cc1 -triple x86_64-apple-darwin -emit-llvm %s -o - | FileCheck %s
Migrate most of the rest of test/FrontendC from llvm and migrate most of them to FileCheck. llvm-svn: 136159
2011-07-27 06:17:02 +08:00
signed char sc;
unsigned char uc;
signed short ss;
unsigned short us;
signed int si;
unsigned int ui;
signed long long sll;
unsigned long long ull;
CHECK-LABEL-ify some code gen tests to improve diagnostic experience when tests fail. llvm-svn: 188447
2013-08-15 14:47:53 +08:00
void test_op_ignore (void) // CHECK-LABEL: define void @test_op_ignore
Migrate most of the rest of test/FrontendC from llvm and migrate most of them to FileCheck. llvm-svn: 136159
2011-07-27 06:17:02 +08:00
{
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 09:41:24 +08:00
(void) __sync_fetch_and_add (&sc, 1); // CHECK: atomicrmw add i8
(void) __sync_fetch_and_add (&uc, 1); // CHECK: atomicrmw add i8
(void) __sync_fetch_and_add (&ss, 1); // CHECK: atomicrmw add i16
(void) __sync_fetch_and_add (&us, 1); // CHECK: atomicrmw add i16
(void) __sync_fetch_and_add (&si, 1); // CHECK: atomicrmw add i32
(void) __sync_fetch_and_add (&ui, 1); // CHECK: atomicrmw add i32
(void) __sync_fetch_and_add (&sll, 1); // CHECK: atomicrmw add i64
(void) __sync_fetch_and_add (&ull, 1); // CHECK: atomicrmw add i64
(void) __sync_fetch_and_sub (&sc, 1); // CHECK: atomicrmw sub i8
(void) __sync_fetch_and_sub (&uc, 1); // CHECK: atomicrmw sub i8
(void) __sync_fetch_and_sub (&ss, 1); // CHECK: atomicrmw sub i16
(void) __sync_fetch_and_sub (&us, 1); // CHECK: atomicrmw sub i16
(void) __sync_fetch_and_sub (&si, 1); // CHECK: atomicrmw sub i32
(void) __sync_fetch_and_sub (&ui, 1); // CHECK: atomicrmw sub i32
(void) __sync_fetch_and_sub (&sll, 1); // CHECK: atomicrmw sub i64
(void) __sync_fetch_and_sub (&ull, 1); // CHECK: atomicrmw sub i64
(void) __sync_fetch_and_or (&sc, 1); // CHECK: atomicrmw or i8
(void) __sync_fetch_and_or (&uc, 1); // CHECK: atomicrmw or i8
(void) __sync_fetch_and_or (&ss, 1); // CHECK: atomicrmw or i16
(void) __sync_fetch_and_or (&us, 1); // CHECK: atomicrmw or i16
(void) __sync_fetch_and_or (&si, 1); // CHECK: atomicrmw or i32
(void) __sync_fetch_and_or (&ui, 1); // CHECK: atomicrmw or i32
(void) __sync_fetch_and_or (&sll, 1); // CHECK: atomicrmw or i64
(void) __sync_fetch_and_or (&ull, 1); // CHECK: atomicrmw or i64
(void) __sync_fetch_and_xor (&sc, 1); // CHECK: atomicrmw xor i8
(void) __sync_fetch_and_xor (&uc, 1); // CHECK: atomicrmw xor i8
(void) __sync_fetch_and_xor (&ss, 1); // CHECK: atomicrmw xor i16
(void) __sync_fetch_and_xor (&us, 1); // CHECK: atomicrmw xor i16
(void) __sync_fetch_and_xor (&si, 1); // CHECK: atomicrmw xor i32
(void) __sync_fetch_and_xor (&ui, 1); // CHECK: atomicrmw xor i32
(void) __sync_fetch_and_xor (&sll, 1); // CHECK: atomicrmw xor i64
(void) __sync_fetch_and_xor (&ull, 1); // CHECK: atomicrmw xor i64
Add __sync_fetch_and_nand (again) Prior to GCC 4.4, __sync_fetch_and_nand was implemented as: { tmp = *ptr; *ptr = ~tmp & value; return tmp; } but this was changed in GCC 4.4 to be: { tmp = *ptr; *ptr = ~(tmp & value); return tmp; } in response to this change, support for sync_fetch_and_nand (and sync_nand_and_fetch) was removed in r99522 in order to avoid miscompiling code depending on the old semantics. However, at this point: 1. Many years have passed, and the amount of code relying on the old semantics is likely smaller. 2. Through the work of many contributors, all LLVM backends have been updated such that "atomicrmw nand" provides the newer GCC 4.4+ semantics (this process was complete July of 2014 (added to the release notes in r212635). 3. The lack of this intrinsic is now a needless impediment to porting codes from GCC to Clang (I've now seen several examples of this). It is true, however, that we still set GNUC_MINOR to 2 (corresponding to GCC 4.2). To compensate for this, and to address the original concern regarding code relying on the old semantics, I've added a warning that specifically details the fact that the semantics have changed and that we provide the newer semantics. Fixes PR8842. llvm-svn: 218905
2014-10-03 04:53:50 +08:00
(void) __sync_fetch_and_nand (&sc, 1); // CHECK: atomicrmw nand i8
(void) __sync_fetch_and_nand (&uc, 1); // CHECK: atomicrmw nand i8
(void) __sync_fetch_and_nand (&ss, 1); // CHECK: atomicrmw nand i16
(void) __sync_fetch_and_nand (&us, 1); // CHECK: atomicrmw nand i16
(void) __sync_fetch_and_nand (&si, 1); // CHECK: atomicrmw nand i32
(void) __sync_fetch_and_nand (&ui, 1); // CHECK: atomicrmw nand i32
(void) __sync_fetch_and_nand (&sll, 1); // CHECK: atomicrmw nand i64
(void) __sync_fetch_and_nand (&ull, 1); // CHECK: atomicrmw nand i64
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 09:41:24 +08:00
(void) __sync_fetch_and_and (&sc, 1); // CHECK: atomicrmw and i8
(void) __sync_fetch_and_and (&uc, 1); // CHECK: atomicrmw and i8
(void) __sync_fetch_and_and (&ss, 1); // CHECK: atomicrmw and i16
(void) __sync_fetch_and_and (&us, 1); // CHECK: atomicrmw and i16
(void) __sync_fetch_and_and (&si, 1); // CHECK: atomicrmw and i32
(void) __sync_fetch_and_and (&ui, 1); // CHECK: atomicrmw and i32
(void) __sync_fetch_and_and (&sll, 1); // CHECK: atomicrmw and i64
(void) __sync_fetch_and_and (&ull, 1); // CHECK: atomicrmw and i64
Migrate most of the rest of test/FrontendC from llvm and migrate most of them to FileCheck. llvm-svn: 136159
2011-07-27 06:17:02 +08:00
}
CHECK-LABEL-ify some code gen tests to improve diagnostic experience when tests fail. llvm-svn: 188447
2013-08-15 14:47:53 +08:00
void test_fetch_and_op (void) // CHECK-LABEL: define void @test_fetch_and_op
Migrate most of the rest of test/FrontendC from llvm and migrate most of them to FileCheck. llvm-svn: 136159
2011-07-27 06:17:02 +08:00
{
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 09:41:24 +08:00
sc = __sync_fetch_and_add (&sc, 11); // CHECK: atomicrmw add
uc = __sync_fetch_and_add (&uc, 11); // CHECK: atomicrmw add
ss = __sync_fetch_and_add (&ss, 11); // CHECK: atomicrmw add
us = __sync_fetch_and_add (&us, 11); // CHECK: atomicrmw add
si = __sync_fetch_and_add (&si, 11); // CHECK: atomicrmw add
ui = __sync_fetch_and_add (&ui, 11); // CHECK: atomicrmw add
sll = __sync_fetch_and_add (&sll, 11); // CHECK: atomicrmw add
ull = __sync_fetch_and_add (&ull, 11); // CHECK: atomicrmw add
sc = __sync_fetch_and_sub (&sc, 11); // CHECK: atomicrmw sub
uc = __sync_fetch_and_sub (&uc, 11); // CHECK: atomicrmw sub
ss = __sync_fetch_and_sub (&ss, 11); // CHECK: atomicrmw sub
us = __sync_fetch_and_sub (&us, 11); // CHECK: atomicrmw sub
si = __sync_fetch_and_sub (&si, 11); // CHECK: atomicrmw sub
ui = __sync_fetch_and_sub (&ui, 11); // CHECK: atomicrmw sub
sll = __sync_fetch_and_sub (&sll, 11); // CHECK: atomicrmw sub
ull = __sync_fetch_and_sub (&ull, 11); // CHECK: atomicrmw sub
sc = __sync_fetch_and_or (&sc, 11); // CHECK: atomicrmw or
uc = __sync_fetch_and_or (&uc, 11); // CHECK: atomicrmw or
ss = __sync_fetch_and_or (&ss, 11); // CHECK: atomicrmw or
us = __sync_fetch_and_or (&us, 11); // CHECK: atomicrmw or
si = __sync_fetch_and_or (&si, 11); // CHECK: atomicrmw or
ui = __sync_fetch_and_or (&ui, 11); // CHECK: atomicrmw or
sll = __sync_fetch_and_or (&sll, 11); // CHECK: atomicrmw or
ull = __sync_fetch_and_or (&ull, 11); // CHECK: atomicrmw or
sc = __sync_fetch_and_xor (&sc, 11); // CHECK: atomicrmw xor
uc = __sync_fetch_and_xor (&uc, 11); // CHECK: atomicrmw xor
ss = __sync_fetch_and_xor (&ss, 11); // CHECK: atomicrmw xor
us = __sync_fetch_and_xor (&us, 11); // CHECK: atomicrmw xor
si = __sync_fetch_and_xor (&si, 11); // CHECK: atomicrmw xor
ui = __sync_fetch_and_xor (&ui, 11); // CHECK: atomicrmw xor
sll = __sync_fetch_and_xor (&sll, 11); // CHECK: atomicrmw xor
ull = __sync_fetch_and_xor (&ull, 11); // CHECK: atomicrmw xor
Add __sync_fetch_and_nand (again) Prior to GCC 4.4, __sync_fetch_and_nand was implemented as: { tmp = *ptr; *ptr = ~tmp & value; return tmp; } but this was changed in GCC 4.4 to be: { tmp = *ptr; *ptr = ~(tmp & value); return tmp; } in response to this change, support for sync_fetch_and_nand (and sync_nand_and_fetch) was removed in r99522 in order to avoid miscompiling code depending on the old semantics. However, at this point: 1. Many years have passed, and the amount of code relying on the old semantics is likely smaller. 2. Through the work of many contributors, all LLVM backends have been updated such that "atomicrmw nand" provides the newer GCC 4.4+ semantics (this process was complete July of 2014 (added to the release notes in r212635). 3. The lack of this intrinsic is now a needless impediment to porting codes from GCC to Clang (I've now seen several examples of this). It is true, however, that we still set GNUC_MINOR to 2 (corresponding to GCC 4.2). To compensate for this, and to address the original concern regarding code relying on the old semantics, I've added a warning that specifically details the fact that the semantics have changed and that we provide the newer semantics. Fixes PR8842. llvm-svn: 218905
2014-10-03 04:53:50 +08:00
sc = __sync_fetch_and_nand (&sc, 11); // CHECK: atomicrmw nand
uc = __sync_fetch_and_nand (&uc, 11); // CHECK: atomicrmw nand
ss = __sync_fetch_and_nand (&ss, 11); // CHECK: atomicrmw nand
us = __sync_fetch_and_nand (&us, 11); // CHECK: atomicrmw nand
si = __sync_fetch_and_nand (&si, 11); // CHECK: atomicrmw nand
ui = __sync_fetch_and_nand (&ui, 11); // CHECK: atomicrmw nand
sll = __sync_fetch_and_nand (&sll, 11); // CHECK: atomicrmw nand
ull = __sync_fetch_and_nand (&ull, 11); // CHECK: atomicrmw nand
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 09:41:24 +08:00
sc = __sync_fetch_and_and (&sc, 11); // CHECK: atomicrmw and
uc = __sync_fetch_and_and (&uc, 11); // CHECK: atomicrmw and
ss = __sync_fetch_and_and (&ss, 11); // CHECK: atomicrmw and
us = __sync_fetch_and_and (&us, 11); // CHECK: atomicrmw and
si = __sync_fetch_and_and (&si, 11); // CHECK: atomicrmw and
ui = __sync_fetch_and_and (&ui, 11); // CHECK: atomicrmw and
sll = __sync_fetch_and_and (&sll, 11); // CHECK: atomicrmw and
ull = __sync_fetch_and_and (&ull, 11); // CHECK: atomicrmw and
Migrate most of the rest of test/FrontendC from llvm and migrate most of them to FileCheck. llvm-svn: 136159
2011-07-27 06:17:02 +08:00
}
void test_op_and_fetch (void)
{
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 09:41:24 +08:00
sc = __sync_add_and_fetch (&sc, uc); // CHECK: atomicrmw add
uc = __sync_add_and_fetch (&uc, uc); // CHECK: atomicrmw add
ss = __sync_add_and_fetch (&ss, uc); // CHECK: atomicrmw add
us = __sync_add_and_fetch (&us, uc); // CHECK: atomicrmw add
si = __sync_add_and_fetch (&si, uc); // CHECK: atomicrmw add
ui = __sync_add_and_fetch (&ui, uc); // CHECK: atomicrmw add
sll = __sync_add_and_fetch (&sll, uc); // CHECK: atomicrmw add
ull = __sync_add_and_fetch (&ull, uc); // CHECK: atomicrmw add
sc = __sync_sub_and_fetch (&sc, uc); // CHECK: atomicrmw sub
uc = __sync_sub_and_fetch (&uc, uc); // CHECK: atomicrmw sub
ss = __sync_sub_and_fetch (&ss, uc); // CHECK: atomicrmw sub
us = __sync_sub_and_fetch (&us, uc); // CHECK: atomicrmw sub
si = __sync_sub_and_fetch (&si, uc); // CHECK: atomicrmw sub
ui = __sync_sub_and_fetch (&ui, uc); // CHECK: atomicrmw sub
sll = __sync_sub_and_fetch (&sll, uc); // CHECK: atomicrmw sub
ull = __sync_sub_and_fetch (&ull, uc); // CHECK: atomicrmw sub
sc = __sync_or_and_fetch (&sc, uc); // CHECK: atomicrmw or
uc = __sync_or_and_fetch (&uc, uc); // CHECK: atomicrmw or
ss = __sync_or_and_fetch (&ss, uc); // CHECK: atomicrmw or
us = __sync_or_and_fetch (&us, uc); // CHECK: atomicrmw or
si = __sync_or_and_fetch (&si, uc); // CHECK: atomicrmw or
ui = __sync_or_and_fetch (&ui, uc); // CHECK: atomicrmw or
sll = __sync_or_and_fetch (&sll, uc); // CHECK: atomicrmw or
ull = __sync_or_and_fetch (&ull, uc); // CHECK: atomicrmw or
sc = __sync_xor_and_fetch (&sc, uc); // CHECK: atomicrmw xor
uc = __sync_xor_and_fetch (&uc, uc); // CHECK: atomicrmw xor
ss = __sync_xor_and_fetch (&ss, uc); // CHECK: atomicrmw xor
us = __sync_xor_and_fetch (&us, uc); // CHECK: atomicrmw xor
si = __sync_xor_and_fetch (&si, uc); // CHECK: atomicrmw xor
ui = __sync_xor_and_fetch (&ui, uc); // CHECK: atomicrmw xor
sll = __sync_xor_and_fetch (&sll, uc); // CHECK: atomicrmw xor
ull = __sync_xor_and_fetch (&ull, uc); // CHECK: atomicrmw xor
Add __sync_fetch_and_nand (again) Prior to GCC 4.4, __sync_fetch_and_nand was implemented as: { tmp = *ptr; *ptr = ~tmp & value; return tmp; } but this was changed in GCC 4.4 to be: { tmp = *ptr; *ptr = ~(tmp & value); return tmp; } in response to this change, support for sync_fetch_and_nand (and sync_nand_and_fetch) was removed in r99522 in order to avoid miscompiling code depending on the old semantics. However, at this point: 1. Many years have passed, and the amount of code relying on the old semantics is likely smaller. 2. Through the work of many contributors, all LLVM backends have been updated such that "atomicrmw nand" provides the newer GCC 4.4+ semantics (this process was complete July of 2014 (added to the release notes in r212635). 3. The lack of this intrinsic is now a needless impediment to porting codes from GCC to Clang (I've now seen several examples of this). It is true, however, that we still set GNUC_MINOR to 2 (corresponding to GCC 4.2). To compensate for this, and to address the original concern regarding code relying on the old semantics, I've added a warning that specifically details the fact that the semantics have changed and that we provide the newer semantics. Fixes PR8842. llvm-svn: 218905
2014-10-03 04:53:50 +08:00
sc = __sync_nand_and_fetch (&sc, uc); // CHECK: atomicrmw nand
// CHECK: and
// CHECK: xor
uc = __sync_nand_and_fetch (&uc, uc); // CHECK: atomicrmw nand
// CHECK: and
// CHECK: xor
ss = __sync_nand_and_fetch (&ss, uc); // CHECK: atomicrmw nand
// CHECK: and
// CHECK: xor
us = __sync_nand_and_fetch (&us, uc); // CHECK: atomicrmw nand
// CHECK: and
// CHECK: xor
si = __sync_nand_and_fetch (&si, uc); // CHECK: atomicrmw nand
// CHECK: and
// CHECK: xor
ui = __sync_nand_and_fetch (&ui, uc); // CHECK: atomicrmw nand
// CHECK: and
// CHECK: xor
sll = __sync_nand_and_fetch (&sll, uc); // CHECK: atomicrmw nand
// CHECK: and
// CHECK: xor
ull = __sync_nand_and_fetch (&ull, uc); // CHECK: atomicrmw nand
// CHECK: and
// CHECK: xor
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 09:41:24 +08:00
sc = __sync_and_and_fetch (&sc, uc); // CHECK: atomicrmw and
uc = __sync_and_and_fetch (&uc, uc); // CHECK: atomicrmw and
ss = __sync_and_and_fetch (&ss, uc); // CHECK: atomicrmw and
us = __sync_and_and_fetch (&us, uc); // CHECK: atomicrmw and
si = __sync_and_and_fetch (&si, uc); // CHECK: atomicrmw and
ui = __sync_and_and_fetch (&ui, uc); // CHECK: atomicrmw and
sll = __sync_and_and_fetch (&sll, uc); // CHECK: atomicrmw and
ull = __sync_and_and_fetch (&ull, uc); // CHECK: atomicrmw and
Migrate most of the rest of test/FrontendC from llvm and migrate most of them to FileCheck. llvm-svn: 136159
2011-07-27 06:17:02 +08:00
}
void test_compare_and_swap (void)
{
IR-change: cmpxchg operations now return { iN, i1 }. This is a minimal fix for clang. I'll soon add support for generating weak variants when requested, but that's not really necessary for the LLVM change in isolation. llvm-svn: 210907
2014-06-13 22:24:59 +08:00
sc = __sync_val_compare_and_swap (&sc, uc, sc);
// CHECK: [[PAIR:%[a-z0-9._]+]] = cmpxchg i8
// CHECK: extractvalue { i8, i1 } [[PAIR]], 0
uc = __sync_val_compare_and_swap (&uc, uc, sc);
// CHECK: [[PAIR:%[a-z0-9._]+]] = cmpxchg i8
// CHECK: extractvalue { i8, i1 } [[PAIR]], 0
ss = __sync_val_compare_and_swap (&ss, uc, sc);
// CHECK: [[PAIR:%[a-z0-9._]+]] = cmpxchg i16
// CHECK: extractvalue { i16, i1 } [[PAIR]], 0
us = __sync_val_compare_and_swap (&us, uc, sc);
// CHECK: [[PAIR:%[a-z0-9._]+]] = cmpxchg i16
// CHECK: extractvalue { i16, i1 } [[PAIR]], 0
si = __sync_val_compare_and_swap (&si, uc, sc);
// CHECK: [[PAIR:%[a-z0-9._]+]] = cmpxchg i32
// CHECK: extractvalue { i32, i1 } [[PAIR]], 0
ui = __sync_val_compare_and_swap (&ui, uc, sc);
// CHECK: [[PAIR:%[a-z0-9._]+]] = cmpxchg i32
// CHECK: extractvalue { i32, i1 } [[PAIR]], 0
sll = __sync_val_compare_and_swap (&sll, uc, sc);
// CHECK: [[PAIR:%[a-z0-9._]+]] = cmpxchg i64
// CHECK: extractvalue { i64, i1 } [[PAIR]], 0
ull = __sync_val_compare_and_swap (&ull, uc, sc);
// CHECK: [[PAIR:%[a-z0-9._]+]] = cmpxchg i64
// CHECK: extractvalue { i64, i1 } [[PAIR]], 0
ui = __sync_bool_compare_and_swap (&sc, uc, sc);
// CHECK: [[PAIR:%[a-z0-9._]+]] = cmpxchg i8
// CHECK: extractvalue { i8, i1 } [[PAIR]], 1
ui = __sync_bool_compare_and_swap (&uc, uc, sc);
// CHECK: [[PAIR:%[a-z0-9._]+]] = cmpxchg i8
// CHECK: extractvalue { i8, i1 } [[PAIR]], 1
ui = __sync_bool_compare_and_swap (&ss, uc, sc);
// CHECK: [[PAIR:%[a-z0-9._]+]] = cmpxchg i16
// CHECK: extractvalue { i16, i1 } [[PAIR]], 1
ui = __sync_bool_compare_and_swap (&us, uc, sc);
// CHECK: [[PAIR:%[a-z0-9._]+]] = cmpxchg i16
// CHECK: extractvalue { i16, i1 } [[PAIR]], 1
ui = __sync_bool_compare_and_swap (&si, uc, sc);
// CHECK: [[PAIR:%[a-z0-9._]+]] = cmpxchg i32
// CHECK: extractvalue { i32, i1 } [[PAIR]], 1
ui = __sync_bool_compare_and_swap (&ui, uc, sc);
// CHECK: [[PAIR:%[a-z0-9._]+]] = cmpxchg i32
// CHECK: extractvalue { i32, i1 } [[PAIR]], 1
ui = __sync_bool_compare_and_swap (&sll, uc, sc);
// CHECK: [[PAIR:%[a-z0-9._]+]] = cmpxchg i64
// CHECK: extractvalue { i64, i1 } [[PAIR]], 1
ui = __sync_bool_compare_and_swap (&ull, uc, sc);
// CHECK: [[PAIR:%[a-z0-9._]+]] = cmpxchg i64
// CHECK: extractvalue { i64, i1 } [[PAIR]], 1
Migrate most of the rest of test/FrontendC from llvm and migrate most of them to FileCheck. llvm-svn: 136159
2011-07-27 06:17:02 +08:00
}
void test_lock (void)
{
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 09:41:24 +08:00
sc = __sync_lock_test_and_set (&sc, 1); // CHECK: atomicrmw xchg i8
uc = __sync_lock_test_and_set (&uc, 1); // CHECK: atomicrmw xchg i8
ss = __sync_lock_test_and_set (&ss, 1); // CHECK: atomicrmw xchg i16
us = __sync_lock_test_and_set (&us, 1); // CHECK: atomicrmw xchg i16
si = __sync_lock_test_and_set (&si, 1); // CHECK: atomicrmw xchg i32
ui = __sync_lock_test_and_set (&ui, 1); // CHECK: atomicrmw xchg i32
sll = __sync_lock_test_and_set (&sll, 1); // CHECK: atomicrmw xchg i64
ull = __sync_lock_test_and_set (&ull, 1); // CHECK: atomicrmw xchg i64
__sync_synchronize (); // CHECK: fence seq_cst
Re-commit r139643. Make clang use Acquire loads and Release stores where necessary. llvm-svn: 139650
2011-09-14 06:21:56 +08:00
__sync_lock_release (&sc); // CHECK: store atomic {{.*}} release, align 1
__sync_lock_release (&uc); // CHECK: store atomic {{.*}} release, align 1
__sync_lock_release (&ss); // CHECK: store atomic {{.*}} release, align 2
__sync_lock_release (&us); /// CHECK: store atomic {{.*}} release, align 2
__sync_lock_release (&si); // CHECK: store atomic {{.*}} release, align 4
__sync_lock_release (&ui); // CHECK: store atomic {{.*}} release, align 4
__sync_lock_release (&sll); // CHECK: store atomic {{.*}} release, align 8
__sync_lock_release (&ull); // CHECK: store atomic {{.*}} release, align 8
Migrate most of the rest of test/FrontendC from llvm and migrate most of them to FileCheck. llvm-svn: 136159
2011-07-27 06:17:02 +08:00
}