Description
Milestones
- Compile device part of "hello world"-like SYCL application.
- Convert device part of the "hello world"-like SYCL application to SPIR-V format.
- Run "hello world"-like SYCL application via OpenCL on GPU.
- Integrate SYCL compilation flow into clang driver.
- Compile/run multi-source application
- Compile/run multi-source application linking with an external SYCL library
Components to upstream
Device code outlining
Current approach: we added two new attributes to the compiler: sycl_kernel and sycl_device. SYCL runtime is supposed to use these attributes to mark functions in the single source which are supposed to be compiled for the device. Compiler is supposed to understand if there are other functions/constants/variables needed to compiler.
Idea(s) to try: clang has infrastructure to mark the code compiler is supposed to offload for CUDA. We can utilize this infrastructure. E.g. AdaptiveCpp/AdaptiveCpp#34 (comment) contains some ideas how already supported functionality can be re-used.
Patch to LLVM: https://reviews.llvm.org/D60455
Integration header
Current approach: SYCL device compiler emits "integration header", which provides "implementation defined" part of the host/device ABI (e.g. order of parameters captured by SYCL kernel, SYCL kernel function names, etc.)
Idea(s) to try: integration header is required only if SYCL device compiler is used custom host compiler. To enable compilation flow with clang compiler only, we could emit host-side object file instead of integration header.
Driver support
Current approach: we added new toolchain to support SYCL compilation flow. This toolchain handles host/device compilers invocation, translation to SPIR-V, etc.
Idea(s) to try: current approach can be improved by implementing suggestions from Andrew to make implementation more friendly for adding custom back-ends support.
Device code diagnostics
Current approach: we implemented new diagnostic messages in SemaSYCL.cpp for most of the requirements in SYCL specification.
Idea(s) to try: re-use existing delayed diagnostics engine similar to OpenMP/CUDA. Re-using existing infrastructure for device code outlining should help here too.
SPIR-V format support
Current approach: SYCL compilation flow introduced a new LLVM transformation pass (CxxReflower) that adjust SPIR-V type and SPIR-V built-in function names declared in the SYCL headers to match the format described here: https://github.com/KhronosGroup/SPIRV-LLVM-Translator/blob/master/docs/SPIRVRepresentationInLLVM.rst
Idea(s) to try: declare SPIR-V built-ins in the SYCL headers, so that transformation is not required and use device specific lib to transform SPIR-V built-ins otherwise. User can link built-ins implementation with -mlink-builtin-bitcode option. We can use SPIR-V built-ins in SYCL headers and define them in device specific library. For instance, Xilinx tool-chain can implement SPIR-V built-ins as SPIR-df built-ins in device specific library, although it's might be better to use something else to avoid name collision between user defined functions and OpenCL built-ins (e.g. __xilinx_sqrt).
This approach is used for lowering AMDGPU/NVidia specific built-ins. Here is recent patch adding tool-chain support for linking with device library.
https://reviews.llvm.org/D59321 - AMDGPU: Teach toolchain to link ROCm device libs. Take a look at the driver test: test/Driver/rocm-device-libs.cl.
SYCL library
Current approach: sub-project in LLVM project. Currently is tested only with Intel OpenCL drivers.
Idea(s) to try: No obvious changes, but can be adjusted based on external users feedback to make it vendor neutral.