[PATCH] D99190: WIP: [SYCL] Add design document for SYCL mode

Alexey Bader via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Mar 25 06:11:19 PDT 2021


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



More information about the cfe-commits mailing list