yaxunl marked 4 inline comments as done.
Comment at: lib/Headers/opencl.h:15636-15637
@@ +15635,4 @@
+#if defined(__OPENCL_C_VERSION__) && __OPENCL_C_VERSION__ >= 200
+#define PIPE_RESERVE_ID_VALID_BIT (1U << 30)
+#define CLK_NULL_RESERVE_ID
(__builtin_astype(((void*)(~PIPE_RESER
yaxunl marked 8 inline comments as done.
Comment at: lib/Headers/opencl.h:11-13
@@ +10,5 @@
+
+#if !defined(__SPIR32__) && !defined(__SPIR64__)
+#error "This header file should be used with SPIR target only."
+#endif
+
tstellarAMD wrote:
> This should be removed s
tstellarAMD added inline comments.
Comment at: lib/Headers/opencl.h:11-13
@@ +10,5 @@
+
+#if !defined(__SPIR32__) && !defined(__SPIR64__)
+#error "This header file should be used with SPIR target only."
+#endif
+
This should be removed so they can be used with any
yaxunl marked 4 inline comments as done.
Comment at: lib/Headers/opencl.h:13721-13726
@@ +13720,8 @@
+
+/**
+ * Queue a memory fence to ensure correct ordering of memory
+ * operations between work-items of a work-group to
+ * image memory.
+ */
+#define CLK_IMAGE_MEM_FENCE 0x04
pxli168 added inline comments.
Comment at: lib/Headers/opencl.h:13721-13726
@@ +13720,8 @@
+
+/**
+ * Queue a memory fence to ensure correct ordering of memory
+ * operations between work-items of a work-group to
+ * image memory.
+ */
+#define CLK_IMAGE_MEM_FENCE 0x04
+
pxli168 added a comment.
I think merge them into one file is a good idea.
And the layout by sepc order is OK, is will makes the review easy.
http://reviews.llvm.org/D18369
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org
Anastasia added a comment.
In http://reviews.llvm.org/D18369#393323, @yaxunl wrote:
> We need to discuss the layout of the header file.
>
> For the builtin functions, I plan to follow the order of the spec and
> extension spec. If there are difference in 1.2 and 2.0, use condition macro.
>
> For
yaxunl added a comment.
We need to discuss the layout of the header file.
For the builtin functions, I plan to follow the order of the spec and extension
spec. If there are difference in 1.2 and 2.0, use condition macro.
For functions with double or half arguments, we have two options:
1. keep
Anastasia added a comment.
In http://reviews.llvm.org/D18369#389469, @yaxunl wrote:
> One of the difference between opencl-12.cl and opencl-20.cl is opencl-12.cl
> defines
>
> #define const_func __attribute__((const))
> #define readonly __attribute__((pure))
>
>
> and uses them for many f
yaxunl added a comment.
One of the difference between opencl-12.cl and opencl-20.cl is opencl-12.cl
defines
#define const_func __attribute__((const))
#define readonly __attribute__((pure))
and uses them for many functions, e.g.
float const_func __attribute__((overloadable)) acos(float);
yaxunl added a comment.
Anastasia/Alexey/Xiuli,
Do you agree that we should have one single opencl.h instead of headers for
different OpenCL versions?
Since most 1.2 builtins are included in 2.0. I think this is doable.
If no objection, I will try to merge them into one header first then addre
yaxunl added a comment.
> Rather than having a separate header for each version with another header for
> the common parts, couldn't we just have a single header that uses #if guards
> for the version specific functionality? e.g.
>
> size_t __attribute__((overloadable)) get_global_id(uint d
jprice added a subscriber: jprice.
jprice added a comment.
In http://reviews.llvm.org/D18369#387560, @yaxunl wrote:
> In http://reviews.llvm.org/D18369#385799, @Anastasia wrote:
>
> > Is there any chance we could factor out the common bits into separate files
> > to avoid large code repetition?
yaxunl added a comment.
In http://reviews.llvm.org/D18369#385799, @Anastasia wrote:
> Regarding half types since there is inconsistency in both headers (commented
> in CL1.2), should we just enable the extension cl_khr_fp16 in the header and
> then have the overloads with half there with all th
Anastasia added a comment.
Regarding half types since there is inconsistency in both headers (commented in
CL1.2), should we just enable the extension cl_khr_fp16 in the header and then
have the overloads with half there with all the other types? They shouldn't be
visible to custom code unless
15 matches
Mail list logo
