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/atomic_ops.c

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

117 lines
3.3 KiB
C
Raw Normal View History

[CodeGen][RISCV] Fix clang/test/CodeGen/atomic_ops.c for RISC-V By default the RISC-V target doesn't have the atomics standard extension enabled. The first RUN line in `clang/test/CodeGen/atomic_ops.c` didn't specify a target triple, which meant that on RISC-V Linux hosts it would target RISC-V, but because it used clang cc1 we didn't get the toolchain driver functionality to automatically turn on the extensions implied by the target triple (riscv64-linux includes atomics). This would cause the test to fail on RISC-V hosts. This patch changes the test to have RUN lines for two explicit targets, one with native atomics and one without. To work around FileCheck limitations and more accurately match the output, some tests now have separate prefixes for the two cases. Reviewers: jyknight, eli.friedman, lenary, efriedma Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D74847
2020-02-22 03:26:09 +08:00
// RUN: %clang_cc1 -triple x86_64 -emit-llvm %s \
// RUN: -o - | FileCheck -check-prefixes=CHECK,NATIVE %s
// RUN: %clang_cc1 -triple riscv32 -target-feature -a -emit-llvm %s \
// RUN: -o - | FileCheck -check-prefixes=CHECK,LIBCALL %s
Some improvements to the handling of C11 atomic types: - Add atomic-to/from-nonatomic cast types - Emit atomic operations for arithmetic on atomic types - Emit non-atomic stores for initialisation of atomic types, but atomic stores and loads for every other store / load - Add a __atomic_init() intrinsic which does a non-atomic store to an _Atomic() type. This is needed for the corresponding C11 stdatomic.h function. - Enables the relevant __has_feature() checks. The feature isn't 100% complete yet, but it's done enough that we want people testing it. Still to do: - Make the arithmetic operations on atomic types (e.g. Atomic(int) foo = 1; foo++;) use the correct LLVM intrinsic if one exists, not a loop with a cmpxchg. - Add a signal fence builtin - Properly set the fenv state in atomic operations on floating point values - Correctly handle things like _Atomic(_Complex double) which are too large for an atomic cmpxchg on some platforms (this requires working out what 'correctly' means in this context) - Fix the many remaining corner cases llvm-svn: 148242
2012-01-17 01:27:18 +08:00
Fix Sema and IRGen for atomic compound assignment so it has the right semantics when promotions are involved. (As far as I can tell, this only affects some edge cases.) llvm-svn: 158591
2012-06-16 10:19:17 +08:00
void foo(int x)
Some improvements to the handling of C11 atomic types: - Add atomic-to/from-nonatomic cast types - Emit atomic operations for arithmetic on atomic types - Emit non-atomic stores for initialisation of atomic types, but atomic stores and loads for every other store / load - Add a __atomic_init() intrinsic which does a non-atomic store to an _Atomic() type. This is needed for the corresponding C11 stdatomic.h function. - Enables the relevant __has_feature() checks. The feature isn't 100% complete yet, but it's done enough that we want people testing it. Still to do: - Make the arithmetic operations on atomic types (e.g. Atomic(int) foo = 1; foo++;) use the correct LLVM intrinsic if one exists, not a loop with a cmpxchg. - Add a signal fence builtin - Properly set the fenv state in atomic operations on floating point values - Correctly handle things like _Atomic(_Complex double) which are too large for an atomic cmpxchg on some platforms (this requires working out what 'correctly' means in this context) - Fix the many remaining corner cases llvm-svn: 148242
2012-01-17 01:27:18 +08:00
{
_Atomic(int) i = 0;
Fix Sema and IRGen for atomic compound assignment so it has the right semantics when promotions are involved. (As far as I can tell, this only affects some edge cases.) llvm-svn: 158591
2012-06-16 10:19:17 +08:00
_Atomic(short) j = 0;
Some improvements to the handling of C11 atomic types: - Add atomic-to/from-nonatomic cast types - Emit atomic operations for arithmetic on atomic types - Emit non-atomic stores for initialisation of atomic types, but atomic stores and loads for every other store / load - Add a __atomic_init() intrinsic which does a non-atomic store to an _Atomic() type. This is needed for the corresponding C11 stdatomic.h function. - Enables the relevant __has_feature() checks. The feature isn't 100% complete yet, but it's done enough that we want people testing it. Still to do: - Make the arithmetic operations on atomic types (e.g. Atomic(int) foo = 1; foo++;) use the correct LLVM intrinsic if one exists, not a loop with a cmpxchg. - Add a signal fence builtin - Properly set the fenv state in atomic operations on floating point values - Correctly handle things like _Atomic(_Complex double) which are too large for an atomic cmpxchg on some platforms (this requires working out what 'correctly' means in this context) - Fix the many remaining corner cases llvm-svn: 148242
2012-01-17 01:27:18 +08:00
// Check that multiply / divides on atomics produce a cmpxchg loop
Fix Sema and IRGen for atomic compound assignment so it has the right semantics when promotions are involved. (As far as I can tell, this only affects some edge cases.) llvm-svn: 158591
2012-06-16 10:19:17 +08:00
i *= 2;
[CodeGen][RISCV] Fix clang/test/CodeGen/atomic_ops.c for RISC-V By default the RISC-V target doesn't have the atomics standard extension enabled. The first RUN line in `clang/test/CodeGen/atomic_ops.c` didn't specify a target triple, which meant that on RISC-V Linux hosts it would target RISC-V, but because it used clang cc1 we didn't get the toolchain driver functionality to automatically turn on the extensions implied by the target triple (riscv64-linux includes atomics). This would cause the test to fail on RISC-V hosts. This patch changes the test to have RUN lines for two explicit targets, one with native atomics and one without. To work around FileCheck limitations and more accurately match the output, some tests now have separate prefixes for the two cases. Reviewers: jyknight, eli.friedman, lenary, efriedma Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D74847
2020-02-22 03:26:09 +08:00
// NATIVE: mul nsw i32
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
// NATIVE: cmpxchg i32* {{.*}} seq_cst, align 4
[CodeGen][RISCV] Fix clang/test/CodeGen/atomic_ops.c for RISC-V By default the RISC-V target doesn't have the atomics standard extension enabled. The first RUN line in `clang/test/CodeGen/atomic_ops.c` didn't specify a target triple, which meant that on RISC-V Linux hosts it would target RISC-V, but because it used clang cc1 we didn't get the toolchain driver functionality to automatically turn on the extensions implied by the target triple (riscv64-linux includes atomics). This would cause the test to fail on RISC-V hosts. This patch changes the test to have RUN lines for two explicit targets, one with native atomics and one without. To work around FileCheck limitations and more accurately match the output, some tests now have separate prefixes for the two cases. Reviewers: jyknight, eli.friedman, lenary, efriedma Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D74847
2020-02-22 03:26:09 +08:00
// LIBCALL: mul nsw i32
[Clang/Test]: Rename enable_noundef_analysis to disable-noundef-analysis and turn it off by default Turning on `enable_noundef_analysis` flag allows better codegen by removing freeze instructions. I modified clang by renaming `enable_noundef_analysis` flag to `disable-noundef-analysis` and turning it off by default. Test updates are made as a separate patch: D108453 Reviewed By: eugenis Differential Revision: https://reviews.llvm.org/D105169
2022-01-16 17:53:11 +08:00
// LIBCALL: i1 @__atomic_compare_exchange(i32 noundef 4,
Fix Sema and IRGen for atomic compound assignment so it has the right semantics when promotions are involved. (As far as I can tell, this only affects some edge cases.) llvm-svn: 158591
2012-06-16 10:19:17 +08:00
i /= 2;
[CodeGen][RISCV] Fix clang/test/CodeGen/atomic_ops.c for RISC-V By default the RISC-V target doesn't have the atomics standard extension enabled. The first RUN line in `clang/test/CodeGen/atomic_ops.c` didn't specify a target triple, which meant that on RISC-V Linux hosts it would target RISC-V, but because it used clang cc1 we didn't get the toolchain driver functionality to automatically turn on the extensions implied by the target triple (riscv64-linux includes atomics). This would cause the test to fail on RISC-V hosts. This patch changes the test to have RUN lines for two explicit targets, one with native atomics and one without. To work around FileCheck limitations and more accurately match the output, some tests now have separate prefixes for the two cases. Reviewers: jyknight, eli.friedman, lenary, efriedma Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D74847
2020-02-22 03:26:09 +08:00
// NATIVE: sdiv i32
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
// NATIVE: cmpxchg i32* {{.*}} seq_cst, align 4
[CodeGen][RISCV] Fix clang/test/CodeGen/atomic_ops.c for RISC-V By default the RISC-V target doesn't have the atomics standard extension enabled. The first RUN line in `clang/test/CodeGen/atomic_ops.c` didn't specify a target triple, which meant that on RISC-V Linux hosts it would target RISC-V, but because it used clang cc1 we didn't get the toolchain driver functionality to automatically turn on the extensions implied by the target triple (riscv64-linux includes atomics). This would cause the test to fail on RISC-V hosts. This patch changes the test to have RUN lines for two explicit targets, one with native atomics and one without. To work around FileCheck limitations and more accurately match the output, some tests now have separate prefixes for the two cases. Reviewers: jyknight, eli.friedman, lenary, efriedma Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D74847
2020-02-22 03:26:09 +08:00
// LIBCALL: sdiv i32
[Clang/Test]: Rename enable_noundef_analysis to disable-noundef-analysis and turn it off by default Turning on `enable_noundef_analysis` flag allows better codegen by removing freeze instructions. I modified clang by renaming `enable_noundef_analysis` flag to `disable-noundef-analysis` and turning it off by default. Test updates are made as a separate patch: D108453 Reviewed By: eugenis Differential Revision: https://reviews.llvm.org/D105169
2022-01-16 17:53:11 +08:00
// LIBCALL: i1 @__atomic_compare_exchange(i32 noundef 4,
Fix Sema and IRGen for atomic compound assignment so it has the right semantics when promotions are involved. (As far as I can tell, this only affects some edge cases.) llvm-svn: 158591
2012-06-16 10:19:17 +08:00
j /= x;
[CodeGen][RISCV] Fix clang/test/CodeGen/atomic_ops.c for RISC-V By default the RISC-V target doesn't have the atomics standard extension enabled. The first RUN line in `clang/test/CodeGen/atomic_ops.c` didn't specify a target triple, which meant that on RISC-V Linux hosts it would target RISC-V, but because it used clang cc1 we didn't get the toolchain driver functionality to automatically turn on the extensions implied by the target triple (riscv64-linux includes atomics). This would cause the test to fail on RISC-V hosts. This patch changes the test to have RUN lines for two explicit targets, one with native atomics and one without. To work around FileCheck limitations and more accurately match the output, some tests now have separate prefixes for the two cases. Reviewers: jyknight, eli.friedman, lenary, efriedma Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D74847
2020-02-22 03:26:09 +08:00
// NATIVE: sdiv i32
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
// NATIVE: cmpxchg i16* {{.*}} seq_cst, align 2
[CodeGen][RISCV] Fix clang/test/CodeGen/atomic_ops.c for RISC-V By default the RISC-V target doesn't have the atomics standard extension enabled. The first RUN line in `clang/test/CodeGen/atomic_ops.c` didn't specify a target triple, which meant that on RISC-V Linux hosts it would target RISC-V, but because it used clang cc1 we didn't get the toolchain driver functionality to automatically turn on the extensions implied by the target triple (riscv64-linux includes atomics). This would cause the test to fail on RISC-V hosts. This patch changes the test to have RUN lines for two explicit targets, one with native atomics and one without. To work around FileCheck limitations and more accurately match the output, some tests now have separate prefixes for the two cases. Reviewers: jyknight, eli.friedman, lenary, efriedma Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D74847
2020-02-22 03:26:09 +08:00
// LIBCALL: sdiv i32
[Clang/Test]: Rename enable_noundef_analysis to disable-noundef-analysis and turn it off by default Turning on `enable_noundef_analysis` flag allows better codegen by removing freeze instructions. I modified clang by renaming `enable_noundef_analysis` flag to `disable-noundef-analysis` and turning it off by default. Test updates are made as a separate patch: D108453 Reviewed By: eugenis Differential Revision: https://reviews.llvm.org/D105169
2022-01-16 17:53:11 +08:00
// LIBCALL: i1 @__atomic_compare_exchange(i32 noundef 2,
Fix Sema and IRGen for atomic compound assignment so it has the right semantics when promotions are involved. (As far as I can tell, this only affects some edge cases.) llvm-svn: 158591
2012-06-16 10:19:17 +08:00
Some improvements to the handling of C11 atomic types: - Add atomic-to/from-nonatomic cast types - Emit atomic operations for arithmetic on atomic types - Emit non-atomic stores for initialisation of atomic types, but atomic stores and loads for every other store / load - Add a __atomic_init() intrinsic which does a non-atomic store to an _Atomic() type. This is needed for the corresponding C11 stdatomic.h function. - Enables the relevant __has_feature() checks. The feature isn't 100% complete yet, but it's done enough that we want people testing it. Still to do: - Make the arithmetic operations on atomic types (e.g. Atomic(int) foo = 1; foo++;) use the correct LLVM intrinsic if one exists, not a loop with a cmpxchg. - Add a signal fence builtin - Properly set the fenv state in atomic operations on floating point values - Correctly handle things like _Atomic(_Complex double) which are too large for an atomic cmpxchg on some platforms (this requires working out what 'correctly' means in this context) - Fix the many remaining corner cases llvm-svn: 148242
2012-01-17 01:27:18 +08:00
}
CodeGen: Correctly convert atomic bool from i8 to i1 Bools are a little tricky, they are i8 in memory and must be coerced back to i1 before further operations can be performed on them. This fixes PR22577. llvm-svn: 229204
2015-02-14 09:35:07 +08:00
[CGAtomic] Mark atomic libcall functions `nounwind` These functions won't ever unwind. This is useful for MemorySanitizer as it simplifies handling __atomic_load in particular. Differential Revision: https://reviews.llvm.org/D85573
2020-08-14 15:34:01 +08:00
// LIBCALL: declare void @__atomic_load(i32, i8*, i8*, i32) [[LC_ATTRS:#[0-9]+]]
// LIBCALL: declare i1 @__atomic_compare_exchange(i32, i8*, i8*, i8*, i32, i32) [[LC_ATTRS:#[0-9]+]]
CodeGen: Correctly convert atomic bool from i8 to i1 Bools are a little tricky, they are i8 in memory and must be coerced back to i1 before further operations can be performed on them. This fixes PR22577. llvm-svn: 229204
2015-02-14 09:35:07 +08:00
extern _Atomic _Bool b;
Use functions with prototypes when appropriate; NFC A significant number of our tests in C accidentally use functions without prototypes. This patch converts the function signatures to have a prototype for the situations where the test is not specific to K&R C declarations. e.g., void func(); becomes void func(void); This is the tenth batch of tests being updated (there are a significant number of other tests left to be updated).
2022-02-15 22:27:12 +08:00
_Bool bar(void) {
[CodeGen][RISCV] Fix clang/test/CodeGen/atomic_ops.c for RISC-V By default the RISC-V target doesn't have the atomics standard extension enabled. The first RUN line in `clang/test/CodeGen/atomic_ops.c` didn't specify a target triple, which meant that on RISC-V Linux hosts it would target RISC-V, but because it used clang cc1 we didn't get the toolchain driver functionality to automatically turn on the extensions implied by the target triple (riscv64-linux includes atomics). This would cause the test to fail on RISC-V hosts. This patch changes the test to have RUN lines for two explicit targets, one with native atomics and one without. To work around FileCheck limitations and more accurately match the output, some tests now have separate prefixes for the two cases. Reviewers: jyknight, eli.friedman, lenary, efriedma Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D74847
2020-02-22 03:26:09 +08:00
// NATIVE-LABEL: @bar
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
// NATIVE: %[[load:.*]] = load atomic i8, i8* @b seq_cst, align 1
[CodeGen][RISCV] Fix clang/test/CodeGen/atomic_ops.c for RISC-V By default the RISC-V target doesn't have the atomics standard extension enabled. The first RUN line in `clang/test/CodeGen/atomic_ops.c` didn't specify a target triple, which meant that on RISC-V Linux hosts it would target RISC-V, but because it used clang cc1 we didn't get the toolchain driver functionality to automatically turn on the extensions implied by the target triple (riscv64-linux includes atomics). This would cause the test to fail on RISC-V hosts. This patch changes the test to have RUN lines for two explicit targets, one with native atomics and one without. To work around FileCheck limitations and more accurately match the output, some tests now have separate prefixes for the two cases. Reviewers: jyknight, eli.friedman, lenary, efriedma Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D74847
2020-02-22 03:26:09 +08:00
// NATIVE: %[[tobool:.*]] = trunc i8 %[[load]] to i1
// NATIVE: ret i1 %[[tobool]]
// LIBCALL-LABEL: @bar
[Clang/Test]: Rename enable_noundef_analysis to disable-noundef-analysis and turn it off by default Turning on `enable_noundef_analysis` flag allows better codegen by removing freeze instructions. I modified clang by renaming `enable_noundef_analysis` flag to `disable-noundef-analysis` and turning it off by default. Test updates are made as a separate patch: D108453 Reviewed By: eugenis Differential Revision: https://reviews.llvm.org/D105169
2022-01-16 17:53:11 +08:00
// LIBCALL: call void @__atomic_load(i32 noundef 1, i8* noundef @b, i8* noundef %atomic-temp, i32 noundef 5)
[CodeGen][RISCV] Fix clang/test/CodeGen/atomic_ops.c for RISC-V By default the RISC-V target doesn't have the atomics standard extension enabled. The first RUN line in `clang/test/CodeGen/atomic_ops.c` didn't specify a target triple, which meant that on RISC-V Linux hosts it would target RISC-V, but because it used clang cc1 we didn't get the toolchain driver functionality to automatically turn on the extensions implied by the target triple (riscv64-linux includes atomics). This would cause the test to fail on RISC-V hosts. This patch changes the test to have RUN lines for two explicit targets, one with native atomics and one without. To work around FileCheck limitations and more accurately match the output, some tests now have separate prefixes for the two cases. Reviewers: jyknight, eli.friedman, lenary, efriedma Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D74847
2020-02-22 03:26:09 +08:00
// LIBCALL: %[[load:.*]] = load i8, i8* %atomic-temp
// LIBCALL: %[[tobool:.*]] = trunc i8 %[[load]] to i1
// LIBCALL: ret i1 %[[tobool]]
CodeGen: Correctly convert atomic bool from i8 to i1 Bools are a little tricky, they are i8 in memory and must be coerced back to i1 before further operations can be performed on them. This fixes PR22577. llvm-svn: 229204
2015-02-14 09:35:07 +08:00
return b;
}
CodeGen: _Atomic(_Complex) shouldn't crash We could be a little kinder if we did a compare-exchange loop instead of an atomic-load/store pair. llvm-svn: 229212
2015-02-14 09:48:17 +08:00
extern _Atomic(_Complex int) x;
void baz(int y) {
[CodeGen][RISCV] Fix clang/test/CodeGen/atomic_ops.c for RISC-V By default the RISC-V target doesn't have the atomics standard extension enabled. The first RUN line in `clang/test/CodeGen/atomic_ops.c` didn't specify a target triple, which meant that on RISC-V Linux hosts it would target RISC-V, but because it used clang cc1 we didn't get the toolchain driver functionality to automatically turn on the extensions implied by the target triple (riscv64-linux includes atomics). This would cause the test to fail on RISC-V hosts. This patch changes the test to have RUN lines for two explicit targets, one with native atomics and one without. To work around FileCheck limitations and more accurately match the output, some tests now have separate prefixes for the two cases. Reviewers: jyknight, eli.friedman, lenary, efriedma Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D74847
2020-02-22 03:26:09 +08:00
// NATIVE-LABEL: @baz
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
// NATIVE: store atomic i64 {{.*}} seq_cst, align 8
[CodeGen][RISCV] Fix clang/test/CodeGen/atomic_ops.c for RISC-V By default the RISC-V target doesn't have the atomics standard extension enabled. The first RUN line in `clang/test/CodeGen/atomic_ops.c` didn't specify a target triple, which meant that on RISC-V Linux hosts it would target RISC-V, but because it used clang cc1 we didn't get the toolchain driver functionality to automatically turn on the extensions implied by the target triple (riscv64-linux includes atomics). This would cause the test to fail on RISC-V hosts. This patch changes the test to have RUN lines for two explicit targets, one with native atomics and one without. To work around FileCheck limitations and more accurately match the output, some tests now have separate prefixes for the two cases. Reviewers: jyknight, eli.friedman, lenary, efriedma Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D74847
2020-02-22 03:26:09 +08:00
// LIBCALL-LABEL: @baz
// LIBCALL: call void @__atomic_store
CodeGen: _Atomic(_Complex) shouldn't crash We could be a little kinder if we did a compare-exchange loop instead of an atomic-load/store pair. llvm-svn: 229212
2015-02-14 09:48:17 +08:00
x += y;
}
CodeGen: set correct result for atomic compound expressions Atomic compound expressions try to use atomicrmw if possible, but this path doesn't set the Result variable, leaving it to crash in later code if anything ever tries to use the result of the expression. This fixes that issue by recalculating the new value based on the old one atomically loaded.
2019-11-07 21:36:03 +08:00
[CGAtomic] Mark atomic libcall functions `nounwind` These functions won't ever unwind. This is useful for MemorySanitizer as it simplifies handling __atomic_load in particular. Differential Revision: https://reviews.llvm.org/D85573
2020-08-14 15:34:01 +08:00
// LIBCALL: declare void @__atomic_store(i32, i8*, i8*, i32) [[LC_ATTRS:#[0-9]+]]
CodeGen: set correct result for atomic compound expressions Atomic compound expressions try to use atomicrmw if possible, but this path doesn't set the Result variable, leaving it to crash in later code if anything ever tries to use the result of the expression. This fixes that issue by recalculating the new value based on the old one atomically loaded.
2019-11-07 21:36:03 +08:00
_Atomic(int) compound_add(_Atomic(int) in) {
// CHECK-LABEL: @compound_add
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: [[OLD:%.*]] = atomicrmw add i32* {{.*}}, i32 5 seq_cst, align 4
CodeGen: set correct result for atomic compound expressions Atomic compound expressions try to use atomicrmw if possible, but this path doesn't set the Result variable, leaving it to crash in later code if anything ever tries to use the result of the expression. This fixes that issue by recalculating the new value based on the old one atomically loaded.
2019-11-07 21:36:03 +08:00
// CHECK: [[NEW:%.*]] = add i32 [[OLD]], 5
// CHECK: ret i32 [[NEW]]
return (in += 5);
}
_Atomic(int) compound_sub(_Atomic(int) in) {
// CHECK-LABEL: @compound_sub
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: [[OLD:%.*]] = atomicrmw sub i32* {{.*}}, i32 5 seq_cst, align 4
CodeGen: set correct result for atomic compound expressions Atomic compound expressions try to use atomicrmw if possible, but this path doesn't set the Result variable, leaving it to crash in later code if anything ever tries to use the result of the expression. This fixes that issue by recalculating the new value based on the old one atomically loaded.
2019-11-07 21:36:03 +08:00
// CHECK: [[NEW:%.*]] = sub i32 [[OLD]], 5
// CHECK: ret i32 [[NEW]]
return (in -= 5);
}
_Atomic(int) compound_xor(_Atomic(int) in) {
// CHECK-LABEL: @compound_xor
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: [[OLD:%.*]] = atomicrmw xor i32* {{.*}}, i32 5 seq_cst, align 4
CodeGen: set correct result for atomic compound expressions Atomic compound expressions try to use atomicrmw if possible, but this path doesn't set the Result variable, leaving it to crash in later code if anything ever tries to use the result of the expression. This fixes that issue by recalculating the new value based on the old one atomically loaded.
2019-11-07 21:36:03 +08:00
// CHECK: [[NEW:%.*]] = xor i32 [[OLD]], 5
// CHECK: ret i32 [[NEW]]
return (in ^= 5);
}
_Atomic(int) compound_or(_Atomic(int) in) {
// CHECK-LABEL: @compound_or
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: [[OLD:%.*]] = atomicrmw or i32* {{.*}}, i32 5 seq_cst, align 4
CodeGen: set correct result for atomic compound expressions Atomic compound expressions try to use atomicrmw if possible, but this path doesn't set the Result variable, leaving it to crash in later code if anything ever tries to use the result of the expression. This fixes that issue by recalculating the new value based on the old one atomically loaded.
2019-11-07 21:36:03 +08:00
// CHECK: [[NEW:%.*]] = or i32 [[OLD]], 5
// CHECK: ret i32 [[NEW]]
return (in |= 5);
}
_Atomic(int) compound_and(_Atomic(int) in) {
// CHECK-LABEL: @compound_and
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: [[OLD:%.*]] = atomicrmw and i32* {{.*}}, i32 5 seq_cst, align 4
CodeGen: set correct result for atomic compound expressions Atomic compound expressions try to use atomicrmw if possible, but this path doesn't set the Result variable, leaving it to crash in later code if anything ever tries to use the result of the expression. This fixes that issue by recalculating the new value based on the old one atomically loaded.
2019-11-07 21:36:03 +08:00
// CHECK: [[NEW:%.*]] = and i32 [[OLD]], 5
// CHECK: ret i32 [[NEW]]
return (in &= 5);
}
_Atomic(int) compound_mul(_Atomic(int) in) {
[CodeGen][RISCV] Fix clang/test/CodeGen/atomic_ops.c for RISC-V By default the RISC-V target doesn't have the atomics standard extension enabled. The first RUN line in `clang/test/CodeGen/atomic_ops.c` didn't specify a target triple, which meant that on RISC-V Linux hosts it would target RISC-V, but because it used clang cc1 we didn't get the toolchain driver functionality to automatically turn on the extensions implied by the target triple (riscv64-linux includes atomics). This would cause the test to fail on RISC-V hosts. This patch changes the test to have RUN lines for two explicit targets, one with native atomics and one without. To work around FileCheck limitations and more accurately match the output, some tests now have separate prefixes for the two cases. Reviewers: jyknight, eli.friedman, lenary, efriedma Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D74847
2020-02-22 03:26:09 +08:00
// NATIVE-LABEL: @compound_mul
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
// NATIVE: cmpxchg i32* {{%.*}}, i32 {{%.*}}, i32 [[NEW:%.*]] seq_cst seq_cst, align 4
[CodeGen][RISCV] Fix clang/test/CodeGen/atomic_ops.c for RISC-V By default the RISC-V target doesn't have the atomics standard extension enabled. The first RUN line in `clang/test/CodeGen/atomic_ops.c` didn't specify a target triple, which meant that on RISC-V Linux hosts it would target RISC-V, but because it used clang cc1 we didn't get the toolchain driver functionality to automatically turn on the extensions implied by the target triple (riscv64-linux includes atomics). This would cause the test to fail on RISC-V hosts. This patch changes the test to have RUN lines for two explicit targets, one with native atomics and one without. To work around FileCheck limitations and more accurately match the output, some tests now have separate prefixes for the two cases. Reviewers: jyknight, eli.friedman, lenary, efriedma Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D74847
2020-02-22 03:26:09 +08:00
// NATIVE: ret i32 [[NEW]]
// LIBCALL-LABEL: @compound_mul
[Clang/Test]: Rename enable_noundef_analysis to disable-noundef-analysis and turn it off by default Turning on `enable_noundef_analysis` flag allows better codegen by removing freeze instructions. I modified clang by renaming `enable_noundef_analysis` flag to `disable-noundef-analysis` and turning it off by default. Test updates are made as a separate patch: D108453 Reviewed By: eugenis Differential Revision: https://reviews.llvm.org/D105169
2022-01-16 17:53:11 +08:00
// LIBCALL: i1 @__atomic_compare_exchange(i32 noundef 4,
CodeGen: set correct result for atomic compound expressions Atomic compound expressions try to use atomicrmw if possible, but this path doesn't set the Result variable, leaving it to crash in later code if anything ever tries to use the result of the expression. This fixes that issue by recalculating the new value based on the old one atomically loaded.
2019-11-07 21:36:03 +08:00
return (in *= 5);
}
[CGAtomic] Mark atomic libcall functions `nounwind` These functions won't ever unwind. This is useful for MemorySanitizer as it simplifies handling __atomic_load in particular. Differential Revision: https://reviews.llvm.org/D85573
2020-08-14 15:34:01 +08:00
// LIBCALL: [[LC_ATTRS]] = { nounwind willreturn }