KhronosGroup / KhronosGroup/SYCL-Docs
Allowing "dead kernel" optimisation
- 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