================
@@ -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
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
