[clang] [SYCL] SYCL host kernel launch support for the sycl_kernel_entry_point attribute. (PR #152403)

[Tom Honermann via cfe-commits]

================
@@ -565,73 +566,84 @@ follows.
 
   namespace sycl {
   class handler {
-    template<typename KernelNameType, typename KernelType>
-    [[ clang::sycl_kernel_entry_point(KernelNameType) ]]
-    static void kernel_entry_point(KernelType kernel) {
-      kernel();
+    template<typename KernelName, typename... Ts>
+    void sycl_kernel_launch(const char* kernelSymbol, Ts&&... kernelArgs) {
----------------
tahonermann wrote:

I don't think use of a reserved identifier is necessary. Name lookup for `sycl_kernel_launch` is performed as-if within the definition of the function declared with the `sycl_kernel_entry_point` attribute. That by itself is not sufficient to avoid ambiguous overload resolution for a function declared at namespace scope, but it does suffice to avoid ambiguity if `sycl_kernel_launch` is declared as a member function or a variable.

Consider the examples at https://godbolt.org/z/h8Ynef7n5. Case 1 does illustrate how an ambiguity can arise if `sycl_kernel_launch` is declared at namespace scope. Cases 2, 3, and 4 demonstrate that such ambiguity does not occur if `sycl_kernel_launch` is declared as a (static or non-static) member function, as a variable at namespace scope, or as a (static) data member. I expect implementations to use the member function approach since that enables convenient sharing of (member) data between the entry point function and `sycl_kernel_launch`. Cases 3 and 4 demonstrate how the customization point object (CPO) idiom can be deployed to circumvent ADL.

https://github.com/llvm/llvm-project/pull/152403