bader added a comment. In D60455#1468386 <https://reviews.llvm.org/D60455#1468386>, @Fznamznon wrote:
> > Ok, my question is whether you are planning to duplicate the same logic as > > for OpenCL kernel which doesn't really seem like an ideal design choice. Is > > this the only difference then we can simply add an extra check for SYCL > > compilation mode in this template handling case. The overall interaction > > between OpenCL and SYCL implementation is still a very big unknown to me so > > it's not very easy to judge about the implementations details... > > Of course, if nothing prevents us to re-use OpenCL kernel attribute for SYCL > I assume it would be good idea. > But I'm thinking about the situation with https://reviews.llvm.org/D60454 . > If we re-use OpenCL kernel attributes - we affected by OpenCL-related changes > and OpenCL-related changes shouldn't violate SYCL semantics. Will it be > usable for SYCL/OpenCL clang developers? @bader , what do you think about it? I also think it's worth trying. We should be able to cover "SYCL semantics" with LIT test to avoid regressions by OpenCL related changes. E.g. add a test case checking that -fsycl-is-device option disables restriction on applying `__kernel` to template functions. I want to confirm that everyone is okay to enable `__kernel` keyword for SYCL extension and cover SYCL use cases with additional regression tests. IIRC, on yesterday call, @keryell, said that having SYCL specific attributes useful for separation of concerns. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D60455/new/ https://reviews.llvm.org/D60455 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
