-
Notifications
You must be signed in to change notification settings - Fork 730
2019 04 01 meeting notes
Do we need a separate mailing list for this WG to discuss issues related to SYCL?
Existing communication channels like LLVM project mailing lists and GitHub project issues is good enough for now.
How to make SYCL easily extensible without changing Clang (https://github.com/intel/llvm/issues/55)
Intel is adding Intel FPGA specific attributes in clang. This might be a problematic for up-streaming SYCL to llvm.org as FPGA targets might require a lot of specialized attributes. Existing infrastructure requires code modifications in multiple places for adding single attribute. One way can mitigate this issue is to improve the infrastructure to simplify adding attributes.
Encourage to write RFC to community about implementing infrastructure for clang attributes. @keryell will send an RFC to LLVM community ~WW15.
Overview of the changes recently uploaded by Intel (https://github.com/intel/llvm/pull/48)
Compiler
- Intel FPGA memory attributes
- SPIR-V translator code base is synced with the latest version
- Switched from using SPIR-V translator as a library to executable in the SYCL compiler
- Function pointers diagnostics is controlled with command line knob
- Added support for multiple target binaries in the same executable
- Clang driver implicitly links SYCL runtime library if -fsycl option is set
Runtime
- Buffer memory can be moved between the contexts
- Fix accessing to subset of SYCL buffer
- Added relational built-ins
- Updated atomic class API and fixed a bug with compare_exchange_strong
Other
- Minor fixes (private address space 5->0, LIT tests)
Review upstream plan (https://github.com/intel/llvm/issues/49)
Can we have separate wiki page or github issue with a table tracking upstream patches status? To keep track of upstreamed patches and what features are supported in llvm.org @bader to create wiki page: SYCL patches upstream status.
Anastasia: Mark patches with a tag - something like "[SYCL]". Start documentation page in clang with SYCL features supported by clang.
Anastasia: I would like to discuss OpenCL code re-use by SYCL compiler in separate github issue. (https://github.com/intel/llvm/issues/59)
Alexey: We added couple of attributes for code outlining. Should we keep with current or re-use existing attributes/pragmas/keywords clang has for CUDA/OpenMP/OpenCL? We would like to have some common infrastructure that can be shared among these extensions. Started discussion in this review request: https://reviews.llvm.org/D60455.
Hal: Reuse of CUDA infrastructure will be positively accepted by community.
Alexey: We use "integration header" approach to de-couple device and host compilers.
Hal: CUDA & OpenMP has Clang only compilation infrastructure. What is the motivation for "integration header"?
Alexey: "Integration header" provides additional information for SYCL runtime, which host compiler can't extract. E.g. kernel function might be a lambda function and C++ specification doesn't define the order of captured values (i.e. kernel parameters).
Hal: Having host and device compiler in sync (clang) requires design discussion.