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

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

321 lines
17 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;
orrectly generate invert xor value for Binary Atomics of int size > 64 When using __sync_nand_and_fetch with __int128, a problem is found that the wrong value for the 'invert' value gets emitted to the xor in case where the int size is greater than 64 bits. This is because uses of llvm::ConstantInt::get which zero extends the greater than 64 bits, so instead -1 that we require, it end up getting 18446744073709551615 This patch replaces the call to llvm::ConstantInt::get with the call to llvm::Constant::getAllOnesValue which works for all integer types. Reviewers: jfp, erichkeane, rjmccall, hfinkel Differential Revision: https://reviews.llvm.org/D82832
2020-07-08 00:27:20 +08:00
__int128 s128;
unsigned __int128 u128;
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] Add {{.*}} to make tests immune to dso_local/dso_preemptable/(none) differences For a definition (of most linkage types), dso_local is set for ELF -fno-pic/-fpie and COFF, but not for Mach-O. This nuance causes unneeded binary format differences. This patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} ` if there is an explicit linkage. * Clang will set dso_local for Mach-O, which is currently implied by TargetMachine.cpp. This will make COFF/Mach-O and executable ELF similar. * Eventually I hope we can make dso_local the textual LLVM IR default (write explicit "dso_preemptable" when applicable) and -fpic ELF will be similar to everything else. This patch helps move toward that goal.
2020-12-31 12:45:56 +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
{
NFC: update clang tests to check ordering and alignment for atomicrmw/cmpxchg. The ability to specify alignment was recently added, and it's an important property which we should ensure is set as expected by Clang. (Especially before making further changes to Clang's code in this area.) But, because it's on the end of the lines, the existing tests all ignore it. Therefore, update all the tests to also verify the expected alignment for atomicrmw and cmpxchg. While I was in there, I also updated uses of 'load atomic' and 'store atomic', and added the memory ordering, where that was missing.
2021-02-12 06:33:43 +08:00
(void) __sync_fetch_and_add (&sc, 1); // CHECK: atomicrmw add i8* {{.*}} seq_cst, align 1
(void) __sync_fetch_and_add (&uc, 1); // CHECK: atomicrmw add i8* {{.*}} seq_cst, align 1
(void) __sync_fetch_and_add (&ss, 1); // CHECK: atomicrmw add i16* {{.*}} seq_cst, align 2
(void) __sync_fetch_and_add (&us, 1); // CHECK: atomicrmw add i16* {{.*}} seq_cst, align 2
(void) __sync_fetch_and_add (&si, 1); // CHECK: atomicrmw add i32* {{.*}} seq_cst, align 4
(void) __sync_fetch_and_add (&ui, 1); // CHECK: atomicrmw add i32* {{.*}} seq_cst, align 4
(void) __sync_fetch_and_add (&sll, 1); // CHECK: atomicrmw add i64* {{.*}} seq_cst, align 8
(void) __sync_fetch_and_add (&ull, 1); // CHECK: atomicrmw add i64* {{.*}} seq_cst, align 8
(void) __sync_fetch_and_sub (&sc, 1); // CHECK: atomicrmw sub i8* {{.*}} seq_cst, align 1
(void) __sync_fetch_and_sub (&uc, 1); // CHECK: atomicrmw sub i8* {{.*}} seq_cst, align 1
(void) __sync_fetch_and_sub (&ss, 1); // CHECK: atomicrmw sub i16* {{.*}} seq_cst, align 2
(void) __sync_fetch_and_sub (&us, 1); // CHECK: atomicrmw sub i16* {{.*}} seq_cst, align 2
(void) __sync_fetch_and_sub (&si, 1); // CHECK: atomicrmw sub i32* {{.*}} seq_cst, align 4
(void) __sync_fetch_and_sub (&ui, 1); // CHECK: atomicrmw sub i32* {{.*}} seq_cst, align 4
(void) __sync_fetch_and_sub (&sll, 1); // CHECK: atomicrmw sub i64* {{.*}} seq_cst, align 8
(void) __sync_fetch_and_sub (&ull, 1); // CHECK: atomicrmw sub i64* {{.*}} seq_cst, align 8
(void) __sync_fetch_and_or (&sc, 1); // CHECK: atomicrmw or i8* {{.*}} seq_cst, align 1
(void) __sync_fetch_and_or (&uc, 1); // CHECK: atomicrmw or i8* {{.*}} seq_cst, align 1
(void) __sync_fetch_and_or (&ss, 1); // CHECK: atomicrmw or i16* {{.*}} seq_cst, align 2
(void) __sync_fetch_and_or (&us, 1); // CHECK: atomicrmw or i16* {{.*}} seq_cst, align 2
(void) __sync_fetch_and_or (&si, 1); // CHECK: atomicrmw or i32* {{.*}} seq_cst, align 4
(void) __sync_fetch_and_or (&ui, 1); // CHECK: atomicrmw or i32* {{.*}} seq_cst, align 4
(void) __sync_fetch_and_or (&sll, 1); // CHECK: atomicrmw or i64* {{.*}} seq_cst, align 8
(void) __sync_fetch_and_or (&ull, 1); // CHECK: atomicrmw or i64* {{.*}} seq_cst, align 8
(void) __sync_fetch_and_xor (&sc, 1); // CHECK: atomicrmw xor i8* {{.*}} seq_cst, align 1
(void) __sync_fetch_and_xor (&uc, 1); // CHECK: atomicrmw xor i8* {{.*}} seq_cst, align 1
(void) __sync_fetch_and_xor (&ss, 1); // CHECK: atomicrmw xor i16* {{.*}} seq_cst, align 2
(void) __sync_fetch_and_xor (&us, 1); // CHECK: atomicrmw xor i16* {{.*}} seq_cst, align 2
(void) __sync_fetch_and_xor (&si, 1); // CHECK: atomicrmw xor i32* {{.*}} seq_cst, align 4
(void) __sync_fetch_and_xor (&ui, 1); // CHECK: atomicrmw xor i32* {{.*}} seq_cst, align 4
(void) __sync_fetch_and_xor (&sll, 1); // CHECK: atomicrmw xor i64* {{.*}} seq_cst, align 8
(void) __sync_fetch_and_xor (&ull, 1); // CHECK: atomicrmw xor i64* {{.*}} seq_cst, align 8
(void) __sync_fetch_and_xor (&u128, 1); // CHECK: atomicrmw xor i128* {{.*}} seq_cst, align 16
(void) __sync_fetch_and_xor (&s128, 1); // CHECK: atomicrmw xor i128* {{.*}} seq_cst, align 16
(void) __sync_fetch_and_nand (&sc, 1); // CHECK: atomicrmw nand i8* {{.*}} seq_cst, align 1
(void) __sync_fetch_and_nand (&uc, 1); // CHECK: atomicrmw nand i8* {{.*}} seq_cst, align 1
(void) __sync_fetch_and_nand (&ss, 1); // CHECK: atomicrmw nand i16* {{.*}} seq_cst, align 2
(void) __sync_fetch_and_nand (&us, 1); // CHECK: atomicrmw nand i16* {{.*}} seq_cst, align 2
(void) __sync_fetch_and_nand (&si, 1); // CHECK: atomicrmw nand i32* {{.*}} seq_cst, align 4
(void) __sync_fetch_and_nand (&ui, 1); // CHECK: atomicrmw nand i32* {{.*}} seq_cst, align 4
(void) __sync_fetch_and_nand (&sll, 1); // CHECK: atomicrmw nand i64* {{.*}} seq_cst, align 8
(void) __sync_fetch_and_nand (&ull, 1); // CHECK: atomicrmw nand i64* {{.*}} seq_cst, align 8
(void) __sync_fetch_and_and (&sc, 1); // CHECK: atomicrmw and i8* {{.*}} seq_cst, align 1
(void) __sync_fetch_and_and (&uc, 1); // CHECK: atomicrmw and i8* {{.*}} seq_cst, align 1
(void) __sync_fetch_and_and (&ss, 1); // CHECK: atomicrmw and i16* {{.*}} seq_cst, align 2
(void) __sync_fetch_and_and (&us, 1); // CHECK: atomicrmw and i16* {{.*}} seq_cst, align 2
(void) __sync_fetch_and_and (&si, 1); // CHECK: atomicrmw and i32* {{.*}} seq_cst, align 4
(void) __sync_fetch_and_and (&ui, 1); // CHECK: atomicrmw and i32* {{.*}} seq_cst, align 4
(void) __sync_fetch_and_and (&sll, 1); // CHECK: atomicrmw and i64* {{.*}} seq_cst, align 8
(void) __sync_fetch_and_and (&ull, 1); // CHECK: atomicrmw and i64* {{.*}} seq_cst, 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
}
[test] Add {{.*}} to make tests immune to dso_local/dso_preemptable/(none) differences For a definition (of most linkage types), dso_local is set for ELF -fno-pic/-fpie and COFF, but not for Mach-O. This nuance causes unneeded binary format differences. This patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} ` if there is an explicit linkage. * Clang will set dso_local for Mach-O, which is currently implied by TargetMachine.cpp. This will make COFF/Mach-O and executable ELF similar. * Eventually I hope we can make dso_local the textual LLVM IR default (write explicit "dso_preemptable" when applicable) and -fpic ELF will be similar to everything else. This patch helps move toward that goal.
2020-12-31 12:45:56 +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
orrectly generate invert xor value for Binary Atomics of int size > 64 When using __sync_nand_and_fetch with __int128, a problem is found that the wrong value for the 'invert' value gets emitted to the xor in case where the int size is greater than 64 bits. This is because uses of llvm::ConstantInt::get which zero extends the greater than 64 bits, so instead -1 that we require, it end up getting 18446744073709551615 This patch replaces the call to llvm::ConstantInt::get with the call to llvm::Constant::getAllOnesValue which works for all integer types. Reviewers: jfp, erichkeane, rjmccall, hfinkel Differential Revision: https://reviews.llvm.org/D82832
2020-07-08 00:27:20 +08:00
// CHECK: -1
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
uc = __sync_nand_and_fetch (&uc, uc); // CHECK: atomicrmw nand
// CHECK: and
// CHECK: xor
orrectly generate invert xor value for Binary Atomics of int size > 64 When using __sync_nand_and_fetch with __int128, a problem is found that the wrong value for the 'invert' value gets emitted to the xor in case where the int size is greater than 64 bits. This is because uses of llvm::ConstantInt::get which zero extends the greater than 64 bits, so instead -1 that we require, it end up getting 18446744073709551615 This patch replaces the call to llvm::ConstantInt::get with the call to llvm::Constant::getAllOnesValue which works for all integer types. Reviewers: jfp, erichkeane, rjmccall, hfinkel Differential Revision: https://reviews.llvm.org/D82832
2020-07-08 00:27:20 +08:00
// CHECK: -1
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
ss = __sync_nand_and_fetch (&ss, uc); // CHECK: atomicrmw nand
// CHECK: and
// CHECK: xor
orrectly generate invert xor value for Binary Atomics of int size > 64 When using __sync_nand_and_fetch with __int128, a problem is found that the wrong value for the 'invert' value gets emitted to the xor in case where the int size is greater than 64 bits. This is because uses of llvm::ConstantInt::get which zero extends the greater than 64 bits, so instead -1 that we require, it end up getting 18446744073709551615 This patch replaces the call to llvm::ConstantInt::get with the call to llvm::Constant::getAllOnesValue which works for all integer types. Reviewers: jfp, erichkeane, rjmccall, hfinkel Differential Revision: https://reviews.llvm.org/D82832
2020-07-08 00:27:20 +08:00
// CHECK: -1
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
us = __sync_nand_and_fetch (&us, uc); // CHECK: atomicrmw nand
// CHECK: and
// CHECK: xor
orrectly generate invert xor value for Binary Atomics of int size > 64 When using __sync_nand_and_fetch with __int128, a problem is found that the wrong value for the 'invert' value gets emitted to the xor in case where the int size is greater than 64 bits. This is because uses of llvm::ConstantInt::get which zero extends the greater than 64 bits, so instead -1 that we require, it end up getting 18446744073709551615 This patch replaces the call to llvm::ConstantInt::get with the call to llvm::Constant::getAllOnesValue which works for all integer types. Reviewers: jfp, erichkeane, rjmccall, hfinkel Differential Revision: https://reviews.llvm.org/D82832
2020-07-08 00:27:20 +08:00
// CHECK: -1
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
si = __sync_nand_and_fetch (&si, uc); // CHECK: atomicrmw nand
// CHECK: and
// CHECK: xor
orrectly generate invert xor value for Binary Atomics of int size > 64 When using __sync_nand_and_fetch with __int128, a problem is found that the wrong value for the 'invert' value gets emitted to the xor in case where the int size is greater than 64 bits. This is because uses of llvm::ConstantInt::get which zero extends the greater than 64 bits, so instead -1 that we require, it end up getting 18446744073709551615 This patch replaces the call to llvm::ConstantInt::get with the call to llvm::Constant::getAllOnesValue which works for all integer types. Reviewers: jfp, erichkeane, rjmccall, hfinkel Differential Revision: https://reviews.llvm.org/D82832
2020-07-08 00:27:20 +08:00
// CHECK: -1
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
ui = __sync_nand_and_fetch (&ui, uc); // CHECK: atomicrmw nand
// CHECK: and
// CHECK: xor
orrectly generate invert xor value for Binary Atomics of int size > 64 When using __sync_nand_and_fetch with __int128, a problem is found that the wrong value for the 'invert' value gets emitted to the xor in case where the int size is greater than 64 bits. This is because uses of llvm::ConstantInt::get which zero extends the greater than 64 bits, so instead -1 that we require, it end up getting 18446744073709551615 This patch replaces the call to llvm::ConstantInt::get with the call to llvm::Constant::getAllOnesValue which works for all integer types. Reviewers: jfp, erichkeane, rjmccall, hfinkel Differential Revision: https://reviews.llvm.org/D82832
2020-07-08 00:27:20 +08:00
// CHECK: -1
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
sll = __sync_nand_and_fetch (&sll, uc); // CHECK: atomicrmw nand
// CHECK: and
// CHECK: xor
orrectly generate invert xor value for Binary Atomics of int size > 64 When using __sync_nand_and_fetch with __int128, a problem is found that the wrong value for the 'invert' value gets emitted to the xor in case where the int size is greater than 64 bits. This is because uses of llvm::ConstantInt::get which zero extends the greater than 64 bits, so instead -1 that we require, it end up getting 18446744073709551615 This patch replaces the call to llvm::ConstantInt::get with the call to llvm::Constant::getAllOnesValue which works for all integer types. Reviewers: jfp, erichkeane, rjmccall, hfinkel Differential Revision: https://reviews.llvm.org/D82832
2020-07-08 00:27:20 +08:00
// CHECK: -1
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
ull = __sync_nand_and_fetch (&ull, uc); // CHECK: atomicrmw nand
// CHECK: and
// CHECK: xor
orrectly generate invert xor value for Binary Atomics of int size > 64 When using __sync_nand_and_fetch with __int128, a problem is found that the wrong value for the 'invert' value gets emitted to the xor in case where the int size is greater than 64 bits. This is because uses of llvm::ConstantInt::get which zero extends the greater than 64 bits, so instead -1 that we require, it end up getting 18446744073709551615 This patch replaces the call to llvm::ConstantInt::get with the call to llvm::Constant::getAllOnesValue which works for all integer types. Reviewers: jfp, erichkeane, rjmccall, hfinkel Differential Revision: https://reviews.llvm.org/D82832
2020-07-08 00:27:20 +08:00
// CHECK: -1
u128 = __sync_nand_and_fetch (&u128, uc); // CHECK: atomicrmw nand
// CHECK: and
// CHECK: xor
// CHECK: -1
s128 = __sync_nand_and_fetch (&s128, uc); // CHECK: atomicrmw nand
// CHECK: and
// CHECK: xor
// CHECK: -1
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
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);
NFC: update clang tests to check ordering and alignment for atomicrmw/cmpxchg. The ability to specify alignment was recently added, and it's an important property which we should ensure is set as expected by Clang. (Especially before making further changes to Clang's code in this area.) But, because it's on the end of the lines, the existing tests all ignore it. Therefore, update all the tests to also verify the expected alignment for atomicrmw and cmpxchg. While I was in there, I also updated uses of 'load atomic' and 'store atomic', and added the memory ordering, where that was missing.
2021-02-12 06:33:43 +08:00
// CHECK: [[PAIR:%[a-z0-9._]+]] = cmpxchg i8* {{.*}} seq_cst, align 1
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
// CHECK: extractvalue { i8, i1 } [[PAIR]], 0
uc = __sync_val_compare_and_swap (&uc, uc, sc);
NFC: update clang tests to check ordering and alignment for atomicrmw/cmpxchg. The ability to specify alignment was recently added, and it's an important property which we should ensure is set as expected by Clang. (Especially before making further changes to Clang's code in this area.) But, because it's on the end of the lines, the existing tests all ignore it. Therefore, update all the tests to also verify the expected alignment for atomicrmw and cmpxchg. While I was in there, I also updated uses of 'load atomic' and 'store atomic', and added the memory ordering, where that was missing.
2021-02-12 06:33:43 +08:00
// CHECK: [[PAIR:%[a-z0-9._]+]] = cmpxchg i8* {{.*}} seq_cst, align 1
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
// CHECK: extractvalue { i8, i1 } [[PAIR]], 0
ss = __sync_val_compare_and_swap (&ss, uc, sc);
NFC: update clang tests to check ordering and alignment for atomicrmw/cmpxchg. The ability to specify alignment was recently added, and it's an important property which we should ensure is set as expected by Clang. (Especially before making further changes to Clang's code in this area.) But, because it's on the end of the lines, the existing tests all ignore it. Therefore, update all the tests to also verify the expected alignment for atomicrmw and cmpxchg. While I was in there, I also updated uses of 'load atomic' and 'store atomic', and added the memory ordering, where that was missing.
2021-02-12 06:33:43 +08:00
// CHECK: [[PAIR:%[a-z0-9._]+]] = cmpxchg i16* {{.*}} seq_cst, align 2
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
// CHECK: extractvalue { i16, i1 } [[PAIR]], 0
us = __sync_val_compare_and_swap (&us, uc, sc);
NFC: update clang tests to check ordering and alignment for atomicrmw/cmpxchg. The ability to specify alignment was recently added, and it's an important property which we should ensure is set as expected by Clang. (Especially before making further changes to Clang's code in this area.) But, because it's on the end of the lines, the existing tests all ignore it. Therefore, update all the tests to also verify the expected alignment for atomicrmw and cmpxchg. While I was in there, I also updated uses of 'load atomic' and 'store atomic', and added the memory ordering, where that was missing.
2021-02-12 06:33:43 +08:00
// CHECK: [[PAIR:%[a-z0-9._]+]] = cmpxchg i16* {{.*}} seq_cst, align 2
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
// CHECK: extractvalue { i16, i1 } [[PAIR]], 0
si = __sync_val_compare_and_swap (&si, uc, sc);
NFC: update clang tests to check ordering and alignment for atomicrmw/cmpxchg. The ability to specify alignment was recently added, and it's an important property which we should ensure is set as expected by Clang. (Especially before making further changes to Clang's code in this area.) But, because it's on the end of the lines, the existing tests all ignore it. Therefore, update all the tests to also verify the expected alignment for atomicrmw and cmpxchg. While I was in there, I also updated uses of 'load atomic' and 'store atomic', and added the memory ordering, where that was missing.
2021-02-12 06:33:43 +08:00
// CHECK: [[PAIR:%[a-z0-9._]+]] = cmpxchg i32* {{.*}} seq_cst, align 4
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
// CHECK: extractvalue { i32, i1 } [[PAIR]], 0
ui = __sync_val_compare_and_swap (&ui, uc, sc);
NFC: update clang tests to check ordering and alignment for atomicrmw/cmpxchg. The ability to specify alignment was recently added, and it's an important property which we should ensure is set as expected by Clang. (Especially before making further changes to Clang's code in this area.) But, because it's on the end of the lines, the existing tests all ignore it. Therefore, update all the tests to also verify the expected alignment for atomicrmw and cmpxchg. While I was in there, I also updated uses of 'load atomic' and 'store atomic', and added the memory ordering, where that was missing.
2021-02-12 06:33:43 +08:00
// CHECK: [[PAIR:%[a-z0-9._]+]] = cmpxchg i32* {{.*}} seq_cst, align 4
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
// CHECK: extractvalue { i32, i1 } [[PAIR]], 0
sll = __sync_val_compare_and_swap (&sll, uc, sc);
NFC: update clang tests to check ordering and alignment for atomicrmw/cmpxchg. The ability to specify alignment was recently added, and it's an important property which we should ensure is set as expected by Clang. (Especially before making further changes to Clang's code in this area.) But, because it's on the end of the lines, the existing tests all ignore it. Therefore, update all the tests to also verify the expected alignment for atomicrmw and cmpxchg. While I was in there, I also updated uses of 'load atomic' and 'store atomic', and added the memory ordering, where that was missing.
2021-02-12 06:33:43 +08:00
// CHECK: [[PAIR:%[a-z0-9._]+]] = cmpxchg i64* {{.*}} seq_cst, align 8
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
// CHECK: extractvalue { i64, i1 } [[PAIR]], 0
ull = __sync_val_compare_and_swap (&ull, uc, sc);
NFC: update clang tests to check ordering and alignment for atomicrmw/cmpxchg. The ability to specify alignment was recently added, and it's an important property which we should ensure is set as expected by Clang. (Especially before making further changes to Clang's code in this area.) But, because it's on the end of the lines, the existing tests all ignore it. Therefore, update all the tests to also verify the expected alignment for atomicrmw and cmpxchg. While I was in there, I also updated uses of 'load atomic' and 'store atomic', and added the memory ordering, where that was missing.
2021-02-12 06:33:43 +08:00
// CHECK: [[PAIR:%[a-z0-9._]+]] = cmpxchg i64* {{.*}} seq_cst, align 8
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
// CHECK: extractvalue { i64, i1 } [[PAIR]], 0
ui = __sync_bool_compare_and_swap (&sc, uc, sc);
NFC: update clang tests to check ordering and alignment for atomicrmw/cmpxchg. The ability to specify alignment was recently added, and it's an important property which we should ensure is set as expected by Clang. (Especially before making further changes to Clang's code in this area.) But, because it's on the end of the lines, the existing tests all ignore it. Therefore, update all the tests to also verify the expected alignment for atomicrmw and cmpxchg. While I was in there, I also updated uses of 'load atomic' and 'store atomic', and added the memory ordering, where that was missing.
2021-02-12 06:33:43 +08:00
// CHECK: [[PAIR:%[a-z0-9._]+]] = cmpxchg i8* {{.*}} seq_cst, align 1
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
// CHECK: extractvalue { i8, i1 } [[PAIR]], 1
ui = __sync_bool_compare_and_swap (&uc, uc, sc);
NFC: update clang tests to check ordering and alignment for atomicrmw/cmpxchg. The ability to specify alignment was recently added, and it's an important property which we should ensure is set as expected by Clang. (Especially before making further changes to Clang's code in this area.) But, because it's on the end of the lines, the existing tests all ignore it. Therefore, update all the tests to also verify the expected alignment for atomicrmw and cmpxchg. While I was in there, I also updated uses of 'load atomic' and 'store atomic', and added the memory ordering, where that was missing.
2021-02-12 06:33:43 +08:00
// CHECK: [[PAIR:%[a-z0-9._]+]] = cmpxchg i8* {{.*}} seq_cst, align 1
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
// CHECK: extractvalue { i8, i1 } [[PAIR]], 1
ui = __sync_bool_compare_and_swap (&ss, uc, sc);
NFC: update clang tests to check ordering and alignment for atomicrmw/cmpxchg. The ability to specify alignment was recently added, and it's an important property which we should ensure is set as expected by Clang. (Especially before making further changes to Clang's code in this area.) But, because it's on the end of the lines, the existing tests all ignore it. Therefore, update all the tests to also verify the expected alignment for atomicrmw and cmpxchg. While I was in there, I also updated uses of 'load atomic' and 'store atomic', and added the memory ordering, where that was missing.
2021-02-12 06:33:43 +08:00
// CHECK: [[PAIR:%[a-z0-9._]+]] = cmpxchg i16* {{.*}} seq_cst, align 2
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
// CHECK: extractvalue { i16, i1 } [[PAIR]], 1
ui = __sync_bool_compare_and_swap (&us, uc, sc);
NFC: update clang tests to check ordering and alignment for atomicrmw/cmpxchg. The ability to specify alignment was recently added, and it's an important property which we should ensure is set as expected by Clang. (Especially before making further changes to Clang's code in this area.) But, because it's on the end of the lines, the existing tests all ignore it. Therefore, update all the tests to also verify the expected alignment for atomicrmw and cmpxchg. While I was in there, I also updated uses of 'load atomic' and 'store atomic', and added the memory ordering, where that was missing.
2021-02-12 06:33:43 +08:00
// CHECK: [[PAIR:%[a-z0-9._]+]] = cmpxchg i16* {{.*}} seq_cst, align 2
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
// CHECK: extractvalue { i16, i1 } [[PAIR]], 1
ui = __sync_bool_compare_and_swap (&si, uc, sc);
NFC: update clang tests to check ordering and alignment for atomicrmw/cmpxchg. The ability to specify alignment was recently added, and it's an important property which we should ensure is set as expected by Clang. (Especially before making further changes to Clang's code in this area.) But, because it's on the end of the lines, the existing tests all ignore it. Therefore, update all the tests to also verify the expected alignment for atomicrmw and cmpxchg. While I was in there, I also updated uses of 'load atomic' and 'store atomic', and added the memory ordering, where that was missing.
2021-02-12 06:33:43 +08:00
// CHECK: [[PAIR:%[a-z0-9._]+]] = cmpxchg i32* {{.*}} seq_cst, align 4
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
// CHECK: extractvalue { i32, i1 } [[PAIR]], 1
ui = __sync_bool_compare_and_swap (&ui, uc, sc);
NFC: update clang tests to check ordering and alignment for atomicrmw/cmpxchg. The ability to specify alignment was recently added, and it's an important property which we should ensure is set as expected by Clang. (Especially before making further changes to Clang's code in this area.) But, because it's on the end of the lines, the existing tests all ignore it. Therefore, update all the tests to also verify the expected alignment for atomicrmw and cmpxchg. While I was in there, I also updated uses of 'load atomic' and 'store atomic', and added the memory ordering, where that was missing.
2021-02-12 06:33:43 +08:00
// CHECK: [[PAIR:%[a-z0-9._]+]] = cmpxchg i32* {{.*}} seq_cst, align 4
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
// CHECK: extractvalue { i32, i1 } [[PAIR]], 1
ui = __sync_bool_compare_and_swap (&sll, uc, sc);
NFC: update clang tests to check ordering and alignment for atomicrmw/cmpxchg. The ability to specify alignment was recently added, and it's an important property which we should ensure is set as expected by Clang. (Especially before making further changes to Clang's code in this area.) But, because it's on the end of the lines, the existing tests all ignore it. Therefore, update all the tests to also verify the expected alignment for atomicrmw and cmpxchg. While I was in there, I also updated uses of 'load atomic' and 'store atomic', and added the memory ordering, where that was missing.
2021-02-12 06:33:43 +08:00
// CHECK: [[PAIR:%[a-z0-9._]+]] = cmpxchg i64* {{.*}} seq_cst, align 8
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
// CHECK: extractvalue { i64, i1 } [[PAIR]], 1
ui = __sync_bool_compare_and_swap (&ull, uc, sc);
NFC: update clang tests to check ordering and alignment for atomicrmw/cmpxchg. The ability to specify alignment was recently added, and it's an important property which we should ensure is set as expected by Clang. (Especially before making further changes to Clang's code in this area.) But, because it's on the end of the lines, the existing tests all ignore it. Therefore, update all the tests to also verify the expected alignment for atomicrmw and cmpxchg. While I was in there, I also updated uses of 'load atomic' and 'store atomic', and added the memory ordering, where that was missing.
2021-02-12 06:33:43 +08:00
// CHECK: [[PAIR:%[a-z0-9._]+]] = cmpxchg i64* {{.*}} seq_cst, align 8
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
// 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)
{
NFC: update clang tests to check ordering and alignment for atomicrmw/cmpxchg. The ability to specify alignment was recently added, and it's an important property which we should ensure is set as expected by Clang. (Especially before making further changes to Clang's code in this area.) But, because it's on the end of the lines, the existing tests all ignore it. Therefore, update all the tests to also verify the expected alignment for atomicrmw and cmpxchg. While I was in there, I also updated uses of 'load atomic' and 'store atomic', and added the memory ordering, where that was missing.
2021-02-12 06:33:43 +08:00
sc = __sync_lock_test_and_set (&sc, 1); // CHECK: atomicrmw xchg i8* {{.*}} seq_cst, align 1
uc = __sync_lock_test_and_set (&uc, 1); // CHECK: atomicrmw xchg i8* {{.*}} seq_cst, align 1
ss = __sync_lock_test_and_set (&ss, 1); // CHECK: atomicrmw xchg i16* {{.*}} seq_cst, align 2
us = __sync_lock_test_and_set (&us, 1); // CHECK: atomicrmw xchg i16* {{.*}} seq_cst, align 2
si = __sync_lock_test_and_set (&si, 1); // CHECK: atomicrmw xchg i32* {{.*}} seq_cst, align 4
ui = __sync_lock_test_and_set (&ui, 1); // CHECK: atomicrmw xchg i32* {{.*}} seq_cst, align 4
sll = __sync_lock_test_and_set (&sll, 1); // CHECK: atomicrmw xchg i64* {{.*}} seq_cst, align 8
ull = __sync_lock_test_and_set (&ull, 1); // CHECK: atomicrmw xchg i64* {{.*}} seq_cst, align 8
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
__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
}
Added atomic_fetch_min, max, umin, umax intrinsics to clang. These intrinsics work exactly as all other atomic_fetch_* intrinsics and allow to create *atomicrmw* with ordering. Updated the clang-extensions document. Differential Revision: https://reviews.llvm.org/D46386 llvm-svn: 332193
2018-05-13 15:45:58 +08:00
void test_atomic(void) {
NFC: update clang tests to check ordering and alignment for atomicrmw/cmpxchg. The ability to specify alignment was recently added, and it's an important property which we should ensure is set as expected by Clang. (Especially before making further changes to Clang's code in this area.) But, because it's on the end of the lines, the existing tests all ignore it. Therefore, update all the tests to also verify the expected alignment for atomicrmw and cmpxchg. While I was in there, I also updated uses of 'load atomic' and 'store atomic', and added the memory ordering, where that was missing.
2021-02-12 06:33:43 +08:00
ui = __atomic_fetch_min(&ui, 5, __ATOMIC_RELAXED); // CHECK: atomicrmw umin {{.*}} monotonic, align 4
si = __atomic_fetch_min(&si, 5, __ATOMIC_SEQ_CST); // CHECK: atomicrmw min {{.*}} seq_cst, align 4
ui = __atomic_fetch_max(&ui, 5, __ATOMIC_ACQUIRE); // CHECK: atomicrmw umax {{.*}} acquire, align 4
si = __atomic_fetch_max(&si, 5, __ATOMIC_RELEASE); // CHECK: atomicrmw max {{.*}} release, align 4
Added atomic_fetch_min, max, umin, umax intrinsics to clang. These intrinsics work exactly as all other atomic_fetch_* intrinsics and allow to create *atomicrmw* with ordering. Updated the clang-extensions document. Differential Revision: https://reviews.llvm.org/D46386 llvm-svn: 332193
2018-05-13 15:45:58 +08:00
}