KhronosGroup / KhronosGroup/SYCL-Docs

Move kernel name forward declarability requirements to the reduced feature set

Open
#859 3 comments 0 reactions 1 assignee Claimed by @tahonermann View on GitHub
clarification
Dominant language
JavaScript
Stars
158
Forks
80
Avg merge
7d 6h
Merged PRs (30d)
5

Description

### Specification Version

SYCL 2020 (Revision 9)

### Section Number(s)

https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#sec:naming.kernels
https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#sec:feature-sets.reduced
https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#_library_only_implementation
https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#sec:interfaces.kernels.as.lambdas

### Issue Description

The kernel name restrictions specified in SYCL 2020 [section 5.2, "Naming of kernels"](https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#sec:naming.kernels), are present to accommodate some SYCL implementation strategies; in particular, the integration header strategy employed by the DPC++ oneAPI compiler when invoked with the `-fno-sycl-unnamed-lambda` or `-fsycl-host-compiler` options. These restrictions are necessary when a SYCL-unaware C++ standard compiler is used as the SYCL host compiler.

[Section B.2, "Reduced feature set"](https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#sec:feature-sets.reduced), allows a conforming SYCL implementation to require programmers to specify an explicit kernel name for calls to SYCL invocation functions that pass the result of a lambda expression as the kernel object. This additional requirement is necessary when a SYCL-unaware C++ standard compiler is used as the SYCL host compiler.

The kernel name restrictions are not necessary for implementations that use a SYCL-aware host compiler (such as the DPC++ oneAPI compiler when operating in its default full feature set mode) or are implemented as a standard C++ library since protocols for correlating kernel name types that are not forward declarable can be defined (with the exception of examples like that reported in #857).

The forward declarability requirements can seem arbitrary and capricious to programmers that don't understand the motivation for these restrictions; particularly when the SYCL implementation in use doesn't enforce or diagnose them. Relegating these requirements to the reduced feature set, as was done for the requirement to explicitly specify a kernel name when passing a lambda expression as a kernel to a SYCL invocation function, would simplify the core SYCL specification, simplify the SYCL programming model, and isolate these restrictions to implementations that actually require them.

This issue has been filed to request that the kernel name forward declarability requirements be moved from the core SYCL specification to the reduced feature set.

### Code Example (Optional)

_No response_

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.