2019 05 28 meeting notes

Agenda

• Opens
• SYCL device code outlining attributes (https://reviews.llvm.org/D60455)
  • Discuss blockers and next steps
• C++ to SPIR-V translation (https://github.com/intel/llvm/pull/171)
• Switch SPIR-V types to OpenCL types (https://github.com/intel/llvm/pull/167)
• Lowering of lambda function object (i.e. "SYCL kernel function")
  • Transforming SYCL classes with pointer type members to OpenCL kernel parameters

Meeting notes

Participants: Alexey Bader, James Brodman, Hal Finkel, Nevin Liber, Ronan Keryell, Andrew Gozillon, Victor Lomuller, Mariya Podchishchaeva.

SYCL device code outlining attributes (https://reviews.llvm.org/D60455)

• Ronan and Andrew are okay with adding SYCL specific attribute instead of re-using OpenCL kernel attribute for kernel outlining. Mariya addressed the comments and waiting for new comments/approval.

C++ to SPIR-V translation (https://github.com/intel/llvm/pull/171)

• We prepared a patch removing 15K of lines added to the compiler for lowering C++ into SPIR-V. Victor and Andrew provided positive feedback on that change.
  • Is there any development process changes required to simplify the development of trySYCL compiler based on Intel SYCL implementation? Andrew: nothing required at the moment. New scheduler added a lot of work at our side, we are trying to keep-up with the Intel changes.

Switch SPIR-V types to OpenCL types (https://github.com/intel/llvm/pull/167)

• Intel created a pull request with SPIR-V replaced by OpenCL types exposed in SYCL mode. This should enable some OpenCL diagnostics and provide useful error checking.
• Are there any issues with this approach for other implementers? Victor/Andrew - no.

Lowering of lambda function object (i.e. "SYCL kernel function")

• Intel created a pull request with new details added to the documentation - https://github.com/intel/llvm/pull/177. These details cover SYCL device compiler front-end components: device code outlining and lowering of function objects to OpenCL kernels.

Feedback on compiler order idea

From https://reviews.llvm.org/D60455#1518896

Just a thought, if you parse host code first and provide the device outlining information to the device compilation phase would you then be able to reuse more parsing functionality from OpenCL?

Hal: even if we run the host compiler first (as OpenMP compiler does), we still have to parse code second time. When we parse code by the device compiler, the host part must be "ignored".

Ronan: it's not clear how to exploit this idea.