Skip to content

2019 06 10 meeting notes

Alexey Bader edited this page Aug 5, 2019 · 5 revisions

Agenda

  • Opens
  • libcxx declares __global() function which conflicts with OpenCL keyword (see https://github.com/intel/llvm/issues/186)
  • SYCL device code outlining attributes (https://reviews.llvm.org/D60455)
    • Discuss blockers and next steps
  • Integration header: pro and cons
  • Missing optimization opportunities for device code. E.g. accessor offset, ND-range global offset

Meeting notes

Participants: Mariya Podchishchaeva(Intel), Alexey Bader(Intel), Mike Kinsner(Intel), Oleg Maslov(Intel), Ronan Keryell(Xilinx), Hal Finkel(ANL), Andrew Gozillon(Xilinx), Victor Lomuller(CP), Kevin Petit(ARM)

Opens

No

libcxx declares __global() function which conflicts with OpenCL keyword (see https://github.com/intel/llvm/issues/186)

There are two possible solutions proposed in the comments.

Victor: we exposed OpenCL address spaces via attributes. This solution do not creates new keywords in the language and more flexible than __attribute__((address_space(N))).

Seems like a good compromise. Let's keep working in this direction.

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

No Anastasia on the call. Let's take it offline.

Integration header: pro and cons

Hal: I have no strong opinion regarding host/device code interface, but there are few notes. Clang is aimed to provide good diagnostics and proposed design shouldn't degrade the user experience in SYCL mode. Suggest reviewing the "integration header" approach with clang community (including CUDA/OpenMP developers) via mailing list.

Ronan: integration header allows using different host compiler. SYCL user's code does not use non-standard extensions like pragmas/keywords, so host part can be compiled by any C++ complaint compiler. We can't use GCC + clang cuda device compiler. There are language extension.

Hal: We want to design for the future not the past - i.e. SYCL compiler is not required to utilize CUDA/OpenMP approaches to solve similar tasks. If integration header is the best option here, we can contribute it to the clang, but we must ensure that it doesn't hinders the quality of the compiler. Usability is important. If we only add the value with integraion header, then it's the way to go.

Hal: Integration header is third way to communicate the information between the host and the device in addition to OpenMP and CUDA frameworks.

Hal: Make sure we are not giving up quality/diagnostics/usability with this approach.

AR Alexey B.: send an RFC to the cfe mailing list to discuss integration header approach.

Missing optimization opportunities for device code. E.g. accessor offset, ND-range global offset

There are solutions for this problem which we can borrow from CUDA/OpenMP. It's an area of ongoing discussions in OpenMP working group.

OpenMP approach to solve this problem is to run the host compiler first, generate artifacts useful for the compiler optimizations.

Most likely will require late outlining.

Discussions: devices supporting exceptions should be able to use them in SYCL kernels.

Summary: this is no "read to go" solution for this problem yet.

Clone this wiki locally