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-libcall.c

121 lines
4.7 KiB
C
Raw Normal View History

Fix atomic libcall. This commit fixes a cast instruction assertion failure due to the incompatible type cast. This will only happen when the target requires atomic libcalls. llvm-svn: 204834
2014-03-27 01:35:01 +08:00
// RUN: %clang_cc1 < %s -triple armv5e-none-linux-gnueabi -emit-llvm -O1 | FileCheck %s
[CodeGen] remove/fix checks that will fail when r301923 is recommitted Don't test the optimizer as part of front-end verification. llvm-svn: 301928
2017-05-02 23:20:18 +08:00
// FIXME: This file should not be checking -O1 output.
// Ie, it is testing many IR optimizer passes as part of front-end verification.
Fix atomic libcall. This commit fixes a cast instruction assertion failure due to the incompatible type cast. This will only happen when the target requires atomic libcalls. llvm-svn: 204834
2014-03-27 01:35:01 +08:00
enum memory_order {
memory_order_relaxed, memory_order_consume, memory_order_acquire,
memory_order_release, memory_order_acq_rel, memory_order_seq_cst
};
int *test_c11_atomic_fetch_add_int_ptr(_Atomic(int *) *p) {
// CHECK: test_c11_atomic_fetch_add_int_ptr
CodeGen: Don't completely mess-up optimized atomic libcalls Summary: We did a great job getting this wrong: - We messed up which LLVM IR types to use for arguments and return values. The optimized libcalls use integer types for values. Clang attempted to use the IR type which corresponds to the value passed in instead of using an appropriately sized integer type. This would result in violations of the ABI for, as an example, floating point types. - We didn't bother recording the result of the atomic libcall in the destination memory. Instead, call the functions with arguments matching the type of the libcall prototype's parameters. This fixes PR20780. Differential Revision: http://reviews.llvm.org/D5098 llvm-svn: 216714
2014-08-29 15:27:49 +08:00
// CHECK: {{%[^ ]*}} = tail call i32 @__atomic_fetch_add_4(i8* {{%[0-9]+}}, i32 12, i32 5)
Fix atomic libcall. This commit fixes a cast instruction assertion failure due to the incompatible type cast. This will only happen when the target requires atomic libcalls. llvm-svn: 204834
2014-03-27 01:35:01 +08:00
return __c11_atomic_fetch_add(p, 3, memory_order_seq_cst);
}
int *test_c11_atomic_fetch_sub_int_ptr(_Atomic(int *) *p) {
// CHECK: test_c11_atomic_fetch_sub_int_ptr
CodeGen: Don't completely mess-up optimized atomic libcalls Summary: We did a great job getting this wrong: - We messed up which LLVM IR types to use for arguments and return values. The optimized libcalls use integer types for values. Clang attempted to use the IR type which corresponds to the value passed in instead of using an appropriately sized integer type. This would result in violations of the ABI for, as an example, floating point types. - We didn't bother recording the result of the atomic libcall in the destination memory. Instead, call the functions with arguments matching the type of the libcall prototype's parameters. This fixes PR20780. Differential Revision: http://reviews.llvm.org/D5098 llvm-svn: 216714
2014-08-29 15:27:49 +08:00
// CHECK: {{%[^ ]*}} = tail call i32 @__atomic_fetch_sub_4(i8* {{%[0-9]+}}, i32 20, i32 5)
Fix atomic libcall. This commit fixes a cast instruction assertion failure due to the incompatible type cast. This will only happen when the target requires atomic libcalls. llvm-svn: 204834
2014-03-27 01:35:01 +08:00
return __c11_atomic_fetch_sub(p, 5, memory_order_seq_cst);
}
int test_c11_atomic_fetch_add_int(_Atomic(int) *p) {
// CHECK: test_c11_atomic_fetch_add_int
CodeGen: Don't completely mess-up optimized atomic libcalls Summary: We did a great job getting this wrong: - We messed up which LLVM IR types to use for arguments and return values. The optimized libcalls use integer types for values. Clang attempted to use the IR type which corresponds to the value passed in instead of using an appropriately sized integer type. This would result in violations of the ABI for, as an example, floating point types. - We didn't bother recording the result of the atomic libcall in the destination memory. Instead, call the functions with arguments matching the type of the libcall prototype's parameters. This fixes PR20780. Differential Revision: http://reviews.llvm.org/D5098 llvm-svn: 216714
2014-08-29 15:27:49 +08:00
// CHECK: {{%[^ ]*}} = tail call i32 @__atomic_fetch_add_4(i8* {{%[0-9]+}}, i32 3, i32 5)
Fix atomic libcall. This commit fixes a cast instruction assertion failure due to the incompatible type cast. This will only happen when the target requires atomic libcalls. llvm-svn: 204834
2014-03-27 01:35:01 +08:00
return __c11_atomic_fetch_add(p, 3, memory_order_seq_cst);
}
int test_c11_atomic_fetch_sub_int(_Atomic(int) *p) {
// CHECK: test_c11_atomic_fetch_sub_int
CodeGen: Don't completely mess-up optimized atomic libcalls Summary: We did a great job getting this wrong: - We messed up which LLVM IR types to use for arguments and return values. The optimized libcalls use integer types for values. Clang attempted to use the IR type which corresponds to the value passed in instead of using an appropriately sized integer type. This would result in violations of the ABI for, as an example, floating point types. - We didn't bother recording the result of the atomic libcall in the destination memory. Instead, call the functions with arguments matching the type of the libcall prototype's parameters. This fixes PR20780. Differential Revision: http://reviews.llvm.org/D5098 llvm-svn: 216714
2014-08-29 15:27:49 +08:00
// CHECK: {{%[^ ]*}} = tail call i32 @__atomic_fetch_sub_4(i8* {{%[0-9]+}}, i32 5, i32 5)
Fix atomic libcall. This commit fixes a cast instruction assertion failure due to the incompatible type cast. This will only happen when the target requires atomic libcalls. llvm-svn: 204834
2014-03-27 01:35:01 +08:00
return __c11_atomic_fetch_sub(p, 5, memory_order_seq_cst);
}
int *fp2a(int **p) {
// CHECK: @fp2a
CodeGen: Don't completely mess-up optimized atomic libcalls Summary: We did a great job getting this wrong: - We messed up which LLVM IR types to use for arguments and return values. The optimized libcalls use integer types for values. Clang attempted to use the IR type which corresponds to the value passed in instead of using an appropriately sized integer type. This would result in violations of the ABI for, as an example, floating point types. - We didn't bother recording the result of the atomic libcall in the destination memory. Instead, call the functions with arguments matching the type of the libcall prototype's parameters. This fixes PR20780. Differential Revision: http://reviews.llvm.org/D5098 llvm-svn: 216714
2014-08-29 15:27:49 +08:00
// CHECK: {{%[^ ]*}} = tail call i32 @__atomic_fetch_sub_4(i8* {{%[0-9]+}}, i32 4, i32 0)
Fix atomic libcall. This commit fixes a cast instruction assertion failure due to the incompatible type cast. This will only happen when the target requires atomic libcalls. llvm-svn: 204834
2014-03-27 01:35:01 +08:00
// Note, the GNU builtins do not multiply by sizeof(T)!
return __atomic_fetch_sub(p, 4, memory_order_relaxed);
}
Add missing atomic libcall support. Support for emitting libcalls for __atomic_fetch_nand and __atomic_{add,sub,and,or,xor,nand}_fetch was missing; add it, and some test cases. Differential Revision: http://reviews.llvm.org/D10847 llvm-svn: 244063
2015-08-06 00:57:36 +08:00
int test_atomic_fetch_add(int *p) {
// CHECK: test_atomic_fetch_add
// CHECK: {{%[^ ]*}} = tail call i32 @__atomic_fetch_add_4(i8* {{%[0-9]+}}, i32 55, i32 5)
return __atomic_fetch_add(p, 55, memory_order_seq_cst);
}
int test_atomic_fetch_sub(int *p) {
// CHECK: test_atomic_fetch_sub
// CHECK: {{%[^ ]*}} = tail call i32 @__atomic_fetch_sub_4(i8* {{%[0-9]+}}, i32 55, i32 5)
return __atomic_fetch_sub(p, 55, memory_order_seq_cst);
}
int test_atomic_fetch_and(int *p) {
// CHECK: test_atomic_fetch_and
// CHECK: {{%[^ ]*}} = tail call i32 @__atomic_fetch_and_4(i8* {{%[0-9]+}}, i32 55, i32 5)
return __atomic_fetch_and(p, 55, memory_order_seq_cst);
}
int test_atomic_fetch_or(int *p) {
// CHECK: test_atomic_fetch_or
// CHECK: {{%[^ ]*}} = tail call i32 @__atomic_fetch_or_4(i8* {{%[0-9]+}}, i32 55, i32 5)
return __atomic_fetch_or(p, 55, memory_order_seq_cst);
}
int test_atomic_fetch_xor(int *p) {
// CHECK: test_atomic_fetch_xor
// CHECK: {{%[^ ]*}} = tail call i32 @__atomic_fetch_xor_4(i8* {{%[0-9]+}}, i32 55, i32 5)
return __atomic_fetch_xor(p, 55, memory_order_seq_cst);
}
int test_atomic_fetch_nand(int *p) {
// CHECK: test_atomic_fetch_nand
// CHECK: {{%[^ ]*}} = tail call i32 @__atomic_fetch_nand_4(i8* {{%[0-9]+}}, i32 55, i32 5)
return __atomic_fetch_nand(p, 55, memory_order_seq_cst);
}
int test_atomic_add_fetch(int *p) {
// CHECK: test_atomic_add_fetch
Correct atomic libcall support for __atomic_*_fetch builtins. In r244063, I had caused these builtins to call the same-named library functions, __atomic_*_fetch_SIZE. However, this was incorrect: while those functions are in fact supported by GCC's libatomic, they're not documented by the spec (and gcc doesn't ever call them). Instead, you're /supposed/ to call the __atomic_fetch_* builtins and then redo the operation inline to return the final value. Differential Revision: http://reviews.llvm.org/D14385 llvm-svn: 252920
2015-11-13 02:37:29 +08:00
// CHECK: [[CALL:%[^ ]*]] = tail call i32 @__atomic_fetch_add_4(i8* {{%[0-9]+}}, i32 55, i32 5)
// CHECK: {{%[^ ]*}} = add i32 [[CALL]], 55
Add missing atomic libcall support. Support for emitting libcalls for __atomic_fetch_nand and __atomic_{add,sub,and,or,xor,nand}_fetch was missing; add it, and some test cases. Differential Revision: http://reviews.llvm.org/D10847 llvm-svn: 244063
2015-08-06 00:57:36 +08:00
return __atomic_add_fetch(p, 55, memory_order_seq_cst);
}
int test_atomic_sub_fetch(int *p) {
// CHECK: test_atomic_sub_fetch
Correct atomic libcall support for __atomic_*_fetch builtins. In r244063, I had caused these builtins to call the same-named library functions, __atomic_*_fetch_SIZE. However, this was incorrect: while those functions are in fact supported by GCC's libatomic, they're not documented by the spec (and gcc doesn't ever call them). Instead, you're /supposed/ to call the __atomic_fetch_* builtins and then redo the operation inline to return the final value. Differential Revision: http://reviews.llvm.org/D14385 llvm-svn: 252920
2015-11-13 02:37:29 +08:00
// CHECK: [[CALL:%[^ ]*]] = tail call i32 @__atomic_fetch_sub_4(i8* {{%[0-9]+}}, i32 55, i32 5)
// CHECK: {{%[^ ]*}} = add i32 [[CALL]], -55
Add missing atomic libcall support. Support for emitting libcalls for __atomic_fetch_nand and __atomic_{add,sub,and,or,xor,nand}_fetch was missing; add it, and some test cases. Differential Revision: http://reviews.llvm.org/D10847 llvm-svn: 244063
2015-08-06 00:57:36 +08:00
return __atomic_sub_fetch(p, 55, memory_order_seq_cst);
}
int test_atomic_and_fetch(int *p) {
// CHECK: test_atomic_and_fetch
Correct atomic libcall support for __atomic_*_fetch builtins. In r244063, I had caused these builtins to call the same-named library functions, __atomic_*_fetch_SIZE. However, this was incorrect: while those functions are in fact supported by GCC's libatomic, they're not documented by the spec (and gcc doesn't ever call them). Instead, you're /supposed/ to call the __atomic_fetch_* builtins and then redo the operation inline to return the final value. Differential Revision: http://reviews.llvm.org/D14385 llvm-svn: 252920
2015-11-13 02:37:29 +08:00
// CHECK: [[CALL:%[^ ]*]] = tail call i32 @__atomic_fetch_and_4(i8* {{%[0-9]+}}, i32 55, i32 5)
// CHECK: {{%[^ ]*}} = and i32 [[CALL]], 55
Add missing atomic libcall support. Support for emitting libcalls for __atomic_fetch_nand and __atomic_{add,sub,and,or,xor,nand}_fetch was missing; add it, and some test cases. Differential Revision: http://reviews.llvm.org/D10847 llvm-svn: 244063
2015-08-06 00:57:36 +08:00
return __atomic_and_fetch(p, 55, memory_order_seq_cst);
}
int test_atomic_or_fetch(int *p) {
// CHECK: test_atomic_or_fetch
Correct atomic libcall support for __atomic_*_fetch builtins. In r244063, I had caused these builtins to call the same-named library functions, __atomic_*_fetch_SIZE. However, this was incorrect: while those functions are in fact supported by GCC's libatomic, they're not documented by the spec (and gcc doesn't ever call them). Instead, you're /supposed/ to call the __atomic_fetch_* builtins and then redo the operation inline to return the final value. Differential Revision: http://reviews.llvm.org/D14385 llvm-svn: 252920
2015-11-13 02:37:29 +08:00
// CHECK: [[CALL:%[^ ]*]] = tail call i32 @__atomic_fetch_or_4(i8* {{%[0-9]+}}, i32 55, i32 5)
// CHECK: {{%[^ ]*}} = or i32 [[CALL]], 55
Add missing atomic libcall support. Support for emitting libcalls for __atomic_fetch_nand and __atomic_{add,sub,and,or,xor,nand}_fetch was missing; add it, and some test cases. Differential Revision: http://reviews.llvm.org/D10847 llvm-svn: 244063
2015-08-06 00:57:36 +08:00
return __atomic_or_fetch(p, 55, memory_order_seq_cst);
}
int test_atomic_xor_fetch(int *p) {
// CHECK: test_atomic_xor_fetch
Correct atomic libcall support for __atomic_*_fetch builtins. In r244063, I had caused these builtins to call the same-named library functions, __atomic_*_fetch_SIZE. However, this was incorrect: while those functions are in fact supported by GCC's libatomic, they're not documented by the spec (and gcc doesn't ever call them). Instead, you're /supposed/ to call the __atomic_fetch_* builtins and then redo the operation inline to return the final value. Differential Revision: http://reviews.llvm.org/D14385 llvm-svn: 252920
2015-11-13 02:37:29 +08:00
// CHECK: [[CALL:%[^ ]*]] = tail call i32 @__atomic_fetch_xor_4(i8* {{%[0-9]+}}, i32 55, i32 5)
// CHECK: {{%[^ ]*}} = xor i32 [[CALL]], 55
Add missing atomic libcall support. Support for emitting libcalls for __atomic_fetch_nand and __atomic_{add,sub,and,or,xor,nand}_fetch was missing; add it, and some test cases. Differential Revision: http://reviews.llvm.org/D10847 llvm-svn: 244063
2015-08-06 00:57:36 +08:00
return __atomic_xor_fetch(p, 55, memory_order_seq_cst);
}
int test_atomic_nand_fetch(int *p) {
// CHECK: test_atomic_nand_fetch
Correct atomic libcall support for __atomic_*_fetch builtins. In r244063, I had caused these builtins to call the same-named library functions, __atomic_*_fetch_SIZE. However, this was incorrect: while those functions are in fact supported by GCC's libatomic, they're not documented by the spec (and gcc doesn't ever call them). Instead, you're /supposed/ to call the __atomic_fetch_* builtins and then redo the operation inline to return the final value. Differential Revision: http://reviews.llvm.org/D14385 llvm-svn: 252920
2015-11-13 02:37:29 +08:00
// CHECK: [[CALL:%[^ ]*]] = tail call i32 @__atomic_fetch_nand_4(i8* {{%[0-9]+}}, i32 55, i32 5)
[CodeGen] remove/fix checks that will fail when r301923 is recommitted Don't test the optimizer as part of front-end verification. llvm-svn: 301928
2017-05-02 23:20:18 +08:00
// FIXME: We should not be checking optimized IR. It changes independently of clang.
// FIXME-CHECK: [[AND:%[^ ]*]] = and i32 [[CALL]], 55
// FIXME-CHECK: {{%[^ ]*}} = xor i32 [[AND]], -1
Add missing atomic libcall support. Support for emitting libcalls for __atomic_fetch_nand and __atomic_{add,sub,and,or,xor,nand}_fetch was missing; add it, and some test cases. Differential Revision: http://reviews.llvm.org/D10847 llvm-svn: 244063
2015-08-06 00:57:36 +08:00
return __atomic_nand_fetch(p, 55, memory_order_seq_cst);
}