From c7b3018f23c6dab0b834ff02743fb8c97dbabb30 Mon Sep 17 00:00:00 2001 From: Greg Lueck Date: Fri, 20 Sep 2024 13:20:01 -0400 Subject: [PATCH] Elaborate open issue with free function kernels I forget if we identified this already as an advantage to the enqueue function approach, but it came up recently in a discussion with @tahonermann. I wanted to record it here, so we don't forget when we get around to implementing this. --- .../sycl_ext_oneapi_free_function_kernels.asciidoc | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/sycl/doc/extensions/proposed/sycl_ext_oneapi_free_function_kernels.asciidoc b/sycl/doc/extensions/proposed/sycl_ext_oneapi_free_function_kernels.asciidoc index 7a471b7fa36c6..077c06f26756f 100644 --- a/sycl/doc/extensions/proposed/sycl_ext_oneapi_free_function_kernels.asciidoc +++ b/sycl/doc/extensions/proposed/sycl_ext_oneapi_free_function_kernels.asciidoc @@ -963,6 +963,13 @@ int main() { ``` + Where `kfp` would have some nicer name. ++ +With either form above, it seems like we have enough type information for the +header to check that the types of the actual kernel arguments are implicitly +convertible to the types of the formal kernel parameters, and we can raise a +compile-time error if they are not. +In addition, the header can perform any necessary implicit conversions when +setting the kernel argument values. * We are debating whether we should allow a free function kernel to be defined with an initial "iteration index" parameter such as: