[clang] [SYCL] The sycl_kernel_entry_point attribute. (PR #111389)

[Tom Honermann via cfe-commits]

================
@@ -14296,6 +14296,31 @@ void ASTContext::getFunctionFeatureMap(llvm::StringMap<bool> &FeatureMap,
   }
 }
 
+static SYCLKernelInfo BuildSYCLKernelInfo(ASTContext &Context,
+                                          CanQualType KernelNameType,
+                                          const FunctionDecl *FD) {
+  return { KernelNameType, FD };
+}
+
+void ASTContext::registerSYCLEntryPointFunction(FunctionDecl *FD) {
+  assert(!FD->isInvalidDecl());
+  assert(!FD->isDependentContext());
+
+  const auto *SKEPAttr = FD->getAttr<SYCLKernelEntryPointAttr>();
+  assert(SKEPAttr && "Missing sycl_kernel_entry_point attribute");
+
+  CanQualType KernelNameType = getCanonicalType(SKEPAttr->getKernelName());
+  auto IT = SYCLKernels.find(KernelNameType);
+  if (IT != SYCLKernels.end()) {
+    if (!declaresSameEntity(FD, IT->second.GetKernelEntryPointDecl()))
+      llvm::report_fatal_error("SYCL kernel name conflict");
----------------
tahonermann wrote:

Agreed. That diagnostic is implemented in the staged changes for the next PR; it is one of the ones I had to disable to produce the (surprising to me) symbol versioning result I described. Again, my goal here was to reduce the negative consequences of a missed diagnostic; I think an ICE is preferred over the possibility of an incorrect kernel being called at run-time.

I'm following up internally to do something about the implicit symbol versioning issue. We should have that possibility eliminated before the code generation PR is submitted.

> However, any such diagnostic is going to be imperfect cross-TU, but report_fatal_error cant do that anyway.

Indeed. We'll need to rely on linkers rejecting duplicate symbol definitions for that.

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