[PATCH] D28691: Add OpenCL 2.0 atomic builtin functions as Clang builtin
Anastasia Stulova via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Tue Jun 20 09:40:41 PDT 2017
Anastasia added inline comments.
================
Comment at: include/clang/Basic/Builtins.def:713
+ATOMIC_BUILTIN(__opencl_atomic_fetch_or, "v.", "t")
+ATOMIC_BUILTIN(__opencl_atomic_fetch_xor, "v.", "t")
+
----------------
What about min/max? I believe they will need to have the scope too.
================
Comment at: include/clang/Basic/DiagnosticSemaKinds.td:6956
+ "synchronization scope argument to atomic operation is invalid">;
+def err_atomic_op_has_non_constant_synch_scope : Error<
+ "non-constant synchronization scope argument to atomic operation is not supported">;
----------------
Btw, is this disallowed by the spec? Can't find anything relevant.
================
Comment at: lib/CodeGen/CGAtomic.cpp:678
RValue CodeGenFunction::EmitAtomicExpr(AtomicExpr *E) {
+ bool IsOpenCL = E->isOpenCL();
QualType AtomicTy = E->getPtr()->getType()->getPointeeType();
----------------
Seems short enough to introduce an extra variable here. :)
================
Comment at: lib/CodeGen/CGAtomic.cpp:707
- switch (E->getOp()) {
+ auto Op = E->getOp();
+ switch (Op) {
----------------
The same here... not sure adding an extra variable is helping here. :)
================
Comment at: lib/CodeGen/CGAtomic.cpp:889
+ return V;
+ auto OrigLangAS = E->getType()
+ .getTypePtr()
----------------
Formatting seems to be a bit odd here...
================
Comment at: lib/CodeGen/CGAtomic.cpp:1117
+ "Non-constant synchronization scope not supported");
+ auto sco = (llvm::SynchronizationScope)(
+ cast<llvm::ConstantInt>(Scope)->getZExtValue());
----------------
Variable name doesn't follow the style.
================
Comment at: lib/CodeGen/CGAtomic.cpp:1117
+ "Non-constant synchronization scope not supported");
+ auto sco = (llvm::SynchronizationScope)(
+ cast<llvm::ConstantInt>(Scope)->getZExtValue());
----------------
Anastasia wrote:
> Variable name doesn't follow the style.
could we avoid using C style cast?
================
Comment at: lib/Sema/SemaChecking.cpp:3146
+ Op == AtomicExpr::AO__opencl_atomic_load)
+ ? 0
+ : 1);
----------------
formatting seems odd.
================
Comment at: test/CodeGenOpenCL/atomic-ops-libcall.cl:1
+// RUN: %clang_cc1 < %s -cl-std=CL2.0 -finclude-default-header -triple spir64 -emit-llvm | FileCheck -check-prefix=GEN4 %s
+// RUN: %clang_cc1 < %s -cl-std=CL2.0 -finclude-default-header -triple armv5e-none-linux-gnueabi -emit-llvm | FileCheck -check-prefix=GEN0 %s
----------------
GEN4 -> SPIR
================
Comment at: test/CodeGenOpenCL/atomic-ops-libcall.cl:2
+// RUN: %clang_cc1 < %s -cl-std=CL2.0 -finclude-default-header -triple spir64 -emit-llvm | FileCheck -check-prefix=GEN4 %s
+// RUN: %clang_cc1 < %s -cl-std=CL2.0 -finclude-default-header -triple armv5e-none-linux-gnueabi -emit-llvm | FileCheck -check-prefix=GEN0 %s
+
----------------
GEN0 -> AMDGPU
================
Comment at: test/CodeGenOpenCL/atomic-ops-libcall.cl:4
+
+void f(atomic_int *i, int cmp) {
+ int x;
----------------
Could we use different scopes?
================
Comment at: test/CodeGenOpenCL/atomic-ops.cl:7
+
+#ifndef ALREADY_INCLUDED
+#define ALREADY_INCLUDED
----------------
why do we need this?
================
Comment at: test/CodeGenOpenCL/atomic-ops.cl:15
+ // CHECK: load atomic i32, i32 addrspace(4)* %{{[.0-9A-Z_a-z]+}} singlethread seq_cst
+ int x = __opencl_atomic_load(i, memory_order_seq_cst, memory_scope_work_item);
+}
----------------
I think we could use different scope types all over...
================
Comment at: test/CodeGenOpenCL/atomic-ops.cl:32
+ // CHECK-LABEL: @fi4(
+ // CHECK: [[PAIR:%[.0-9A-Z_a-z]+]] = cmpxchg i32 addrspace(4)* [[PTR:%[.0-9A-Z_a-z]+]], i32 [[EXPECTED:%[.0-9A-Z_a-z]+]], i32 [[DESIRED:%[.0-9A-Z_a-z]+]] singlethread acquire acquire
+ // CHECK: [[OLD:%[.0-9A-Z_a-z]+]] = extractvalue { i32, i1 } [[PAIR]], 0
----------------
do we have an addrspacecast before?
================
Comment at: test/SemaOpenCL/atomic-ops.cl:22
+ intptr_t *P, float *D, struct S *s1, struct S *s2) {
+ __opencl_atomic_init(I, 5); // expected-error {{pointer to _Atomic}}
+ __opencl_atomic_init(ci, 5); // expected-error {{address argument to atomic operation must be a pointer to non-const _Atomic type ('const __generic atomic_int *' (aka 'const __generic _Atomic(int) *') invalid)}}
----------------
could we have the full error for consistency?
================
Comment at: test/SemaOpenCL/atomic-ops.cl:30
+ __opencl_atomic_store(i, 0, memory_order_relaxed, memory_scope_work_item);
+ __opencl_atomic_store(ci, 0, memory_order_relaxed, memory_scope_work_item); // expected-error {{address argument to atomic operation must be a pointer to non-const _Atomic type ('const __generic atomic_int *' (aka 'const __generic _Atomic(int) *') invalid)}}
+
----------------
could we also test with constant AS? Also I would generally improve testing wrt address spaces...
https://reviews.llvm.org/D28691
More information about the cfe-commits
mailing list