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