[PATCH] D60455: [SYCL] Add support for SYCL device attributes

Wed Apr 17 08:30:58 PDT 2019

keryell added a comment.

In D60455#1470030 <https://reviews.llvm.org/D60455#1470030>, @Anastasia wrote:

>

> I am not sure we need to add a keyword actually, the attribute can just be added in AST since it's not supposed to be used in the source code?

The attribute is used by the SYCL headers to mark the functions to be outlined to the device.
https://github.com/intel/llvm/blob/sycl/sycl/include/CL/sycl/handler.hpp#L267
https://github.com/intel/llvm/blob/sycl/sycl/include/CL/sycl/handler.hpp#L295
https://github.com/intel/llvm/blob/sycl/sycl/include/CL/sycl/handler.hpp#L308
https://github.com/intel/llvm/blob/sycl/sycl/include/CL/sycl/handler.hpp#L325

> My understanding of SYCL kernel is that it mainly matches OpenCL kernel functionality because the original intent of SYCL was to provide single source functionality on top of OpenCL.

Yes, this was the idea, when OpenCL was announced in November 2008, to build some higher-level programming models on top of it.
Now the SYCL standard is evolving to something more general to bring heterogeneous computing to modern C++.
So we could reuse in the same way some attributes from OpenMP 5 or CUDA if the Clang/LLVM community thinks it is better.

> But I am not an expert in SYCL to confirm that.

I am pretty sure that the SYCL standard committee would love some active participation from ARM. ;-)

> I think what we are missing currently is a thorough analysis/comparison between SYCL device mode and OpenCL kernel language mode to understand what's the best implementation strategy. That would apply to many other features: kernel function restrictions, address spaces, vectors, special types, etc.

That would make definitely sense when we target OpenCL.

> I still see no point in polluting our code base with extra code that just does the same thing. It will save us a lot of time to just work cooperatively on the same problem and even improve readability of the code. But of course this can only be done if there is no need to diverge the implementation significantly.

Yes. Probably that even when the target is not OpenCL, the general principles remain similar. Probably the same for CUDA & OpenMP 5 too...

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D60455/new/

https://reviews.llvm.org/D60455