bader added a comment.

In 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 . 
> 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.

  rG LLVM Github Monorepo


cfe-commits mailing list

Reply via email to