KhronosGroup / KhronosGroup/SYCL-Docs

Allowing "dead kernel" optimisation

Open
#229 9 comments 0 reactions 0 assignees View on GitHub
enhancement
Dominant language
JavaScript
Stars
158
Forks
80
Avg merge
7d 6h
Merged PRs (30d)
5

Description

Actually the SYCL specification does not allow to remove dead/unreachable kernels at least because of free functions such as `get_kernel_bundle` (which could be called indirectly from another translation unit and use the kernel even if it appears unreachable in the current one). It's not only related to SYCL specifically.
However removing unused kernels could have some advantages (binary size, JIT latency), especially in large projects where codepaths might be unreachable due to compile-time config (and with a lot of macro generated kernels ahah).
Having an attribute such as `[[sycl::inline_kernel]]` would be welcome. Applying it to a kernel would mean it can be discarded in dead code analysis unless its name is used within the current translation unit (or its call site is reachable, of course).

And so something like
```C++
#include
int main(){
auto f = [](){
sycl::queue{}.parallel_for(1000, [] [[sycl::inline_kernel]] (sycl::id id){
(void)id;
});
};
}
```
would compile to nothing (which is kind of what you would expect/want at first sight).

An optimisation that could be done as a result, in a case where online and offline compilation are available, would be to compile offline all the `[[sycl::inline_kernel]]` that were kept after dead code analysis (as they are necessarily used) and use online compilation for the other kernels. We get a tradeoff launch latency and binary size.

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by reviewing the SYCL specification sections governing kernel reachability, dead-code removal, and kernel compilation; the issue names no files or tests. Define the proposed attribute's semantics, interaction with get_kernel_bundle and translation units, and the expected offline/online compilation behavior before considering an implementation or specification update.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
compilers, documentation
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.