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

Tom Honermann via cfe-commits cfe-commits at lists.llvm.org
Wed Dec 10 09:12:14 PST 2025


================
@@ -315,43 +315,53 @@ void SemaSYCL::CheckSYCLEntryPointFunctionDecl(FunctionDecl *FD) {
     }
   }
 
+  if (isa<CXXConstructorDecl>(FD)) {
+    Diag(SKEPAttr->getLocation(), diag::err_sycl_entry_point_invalid)
+        << SKEPAttr << /*constructor*/ 3;
+    SKEPAttr->setInvalidAttr();
+  }
+  if (isa<CXXDestructorDecl>(FD)) {
+    Diag(SKEPAttr->getLocation(), diag::err_sycl_entry_point_invalid)
+        << SKEPAttr << /*destructor*/ 4;
+    SKEPAttr->setInvalidAttr();
+  }
   if (const auto *MD = dyn_cast<CXXMethodDecl>(FD)) {
-    if (!MD->isStatic()) {
+    if (MD->isExplicitObjectMemberFunction()) {
----------------
tahonermann wrote:

The motivation for allowing the `sycl_kernel_entry_point` attribute on non-static member functions is solely so that the call to `sycl_kernel_launch` will have a `this` pointer available. This allows the SYCL RT to store per-invocation state in the enclosing class without having to resort to some kind of (probably type unsafe) context pointer to be passed to `sycl_kernel_launch`.

The support for non-static member functions prohibits (implicit or explicit) use of `this` within the function body (except for in the implicit call to `sycl_kernel_launch()`); see the diagnostic added to `OutlinedFunctionDeclBodyInstantiator::TransformCXXThisExpr()` in `clang/lib/Sema/SemaSYCL.cpp`. We could potentially do similarly for an explicit object parameter, but the desired semantics aren't clear to me. `this` is always a pointer and the pointed to object is never a kernel argument. An explicit object type can be a non-reference/non-pointer type. In that case, should it become a kernel argument? Should the implicit call to `sycl_kernel_launch()` implicitly use the explicit object parameter? With no use case or particular motivation for supporting explicit object parameters, I felt the conservative thing to do is just prohibit their use. We can relax this if motivation arises with clear semantics arises.

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


More information about the cfe-commits mailing list