bader added a comment.
@keryell, thanks for the feedback.
I applied your suggestions with two exceptions:
1. I'm not sure if other back-ends need special processing for kernel function
parameters we apply for SPIR kernels.
2. I'm looking for suggestions on "OpenCL extensions" clarification.
================
Comment at: clang/docs/SYCLSupport.md:127
+special `accessor` classes. The "device" side implementation of these classes
+contains pointers to the device memory. As there is no way in OpenCL to pass
+structures with pointers inside as kernel arguments all memory objects shared
----------------
keryell wrote:
> To be generalized to non OpenCL case.
@Naghasan, do you know if CUDA has similar limitation?
================
Comment at: clang/docs/SYCLSupport.md:140
+To facilitate the mapping of SYCL kernel data members to SPIR kernel arguments
+and overcome OpenCL limitations we added the generation of an SPIR kernel
+function inside the compiler. A SPIR kernel function contains the body of the
----------------
keryell wrote:
> It is not about overcoming some OpenCL limitations but just to use OpenCL as
> a back-end.
I replaced "overcome OpenCL limitations" to "use OpenCL as a back-end", but I
don't see the difference between these two options.
================
Comment at: clang/docs/SYCLSupport.md:155
+
+// Generated kernel function (expressed using OpenCL extensions)
+__kernel KernelName(global int* a) {
----------------
keryell wrote:
> "OpenCL extensions" is probably misleading here and the sentence should be
> clarified.
"OpenCL extensions" are two keywords: `__kernel` and `global`.
Do you have a suggestion how to improve it?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D99190/new/
https://reviews.llvm.org/D99190
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
