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

[Ronan KERYELL via cfe-dev]

>>>>> On Thu, 7 Feb 2019 20:34:17 +0000, "Finkel, Hal J. via cfe-dev" <cfe-dev at lists.llvm.org> said:

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

Actually at Xilinx we are interested by SYCL also without SPIR or SPIR-V
support too, because we do not support it. But interestingly we can use
LLVM IR with our processors, FPGA and CGRA. :-)

As you say, since SYCL is pure C++, we can use any kind of extensions
(inline assembly, attributes, intrinsic functions, etc.) by just letting
them flow through Clang/LLVM, which is a top motivation for us.

While we have some experiments without SPIR-V with
https://github.com/triSYCL/triSYCL , it would be great to have a
production-quality implementation of SYCL up-streamed into Clang/LLVM...

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

Yes they have several back-ends.

There is also another implementation targeting CUDA or hip:
https://github.com/illuhad/hipSYCL

Globally I agree that for all the programming models we should decouple
the front-end languages from the target architectures as much as
possible to develop the ecosystems.
-- 
  Ronan KERYELL.