[cfe-dev] [RFC] Add SYCL programming model support.

[Bader, Alexey via cfe-dev]

?  Are you thinking about supporting SYCL only via lowering to SPIR-V, or also via direct invocation of appropriate hardware backends? One thing that worries me is that SPIR-V does not support function pointers, and while SYCL doesn't either (or virtual functions, as noted on pg 16, ch 2 of the SYCL 1.2.1 spec), given our experience with other accelerator programming models, I'm not sure how many of our applications would find SYCL an appealing model without this support. Thus, while I think that SYCL is an interesting model, and I know a number of developers interested in learning more about it, being trapped into this restriction by a SPIR-V funnel seems highly undesirable. It seems like this could undesirably limit our ability to support extensions of this kind. Support for inline assembly is another important feature that seems like it might have trouble passing through a SPIR-V layer. There might be other SPIR-V restrictions that pose a similar problem.


We are going to support "direct invocation of appropriate hardware backends". There are multiple reasons to support this option including performance benefits from bypassing JIT compilation and that some OpenCL implementations doesn't support SPIR-V (e.g. Intel OpenCL FPGA device can accept only pre-built programs).
I'm fully agree with you on that some SYCL/OpenCL limitations can be relaxed for particular hardware targets (e.g. there should be no reason in additional restrictions for x86 architecture).
I think we can make SYCL restrictions target dependent and/or enforced by compiler knob. This should allow developers to validate portability of SYCL programs across OpenCL capable accelerators and enable use cases where developers prefer performance over portability and use target-specific extensions.



?  I know that ComputeCPP from CodePlay supports some kind of direct-to-PTX path in their LLVM/Clang fork, for example. This is certainly a feature that is important to our current/planned evaluation work regarding SYCL.

This is not something I'm particularly going to work on, but AFAIK there is a PTX back-end in LLVM, so implementing direct-to-PTX path should be straightforward once we have SYCL support in the clang - someone will just need to make sure that SYCL uses NVPTX conventions<https://llvm.org/docs/NVPTXUsage.html#conventions>. BTW, there is significant overlap in NVPTX and SPIR features, if we could unify these it would simplify implementation of this path (e.g. both mark some LLVM functions as "kernels", both support multiple address spaces  - but different mapping, intrinsics can be generalized). I realize that there still might be some differences, but both representations enable programming of GPU architectures and there are similarities even between different vendors.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190208/5c92f2a8/attachment.html>