Do we allow user to use OpenCL and SYCL at same time

[smanna12]

Heh, that may be worth finding out (we can always fix things up later for it). I seem to recall a hazy recollection that users were allowed to mix CUDA and SYCL or OpenCL and SYCL, but perhaps only in host mode. But I don't think this situation is super common, so waiting to resolve it is fine by me.

Originally posted by @AaronBallman in #5592 (comment)

[keryell]

Of course, you can use everything at the same time, independently.
Where it becomes quite more interesting is that SYCL 2020 exposes an interoperability mode with the underlying backends.
So from SYCL you can call an existing OpenCL/CUDA/HIP/... kernel, use an existing OpenCL/CUDA/HIP/... queue, export some SYCL buffer/queue to an existing OpenCL/CUDA/HIP/... libraries, etc.
And you can have all the backends working at the same time on the same machine in the same program.
SYCL is the most inclusive programming model for heterogeneous computing. :-)

[AaronBallman]

Of course, you can use everything at the same time, independently.

This makes for some really interesting thought experiments then. Consider use of __attribute__((reqd_work_group_size)). This attribute is an OpenCL attribute specified by their language standard, and the argument order is X, Y, Z. SYCL also uses this attribute with this spelling, but the argument order for SYCL is Z, Y, X (opposite to OpenCL). How should this work when SYCL and OpenCL are both enabled at the same time?

My belief is that SYCL had no right to steal the attribute from OpenCL and then change its semantics, so the GNU spelling (which has no ability to specify a namespace) should be following the OpenCL semantics even in SYCL mode because OpenCL defined the semantics first.

[keryell]

First, SYCL is a single-source programming model, while OpenCL is a split-source programming model, which means that having SYCL + OpenCL in the same application leads to have in the main C++ source code both SYCL host + SYCL device with these attributes and the host OpenCL API part. All the OpenCL C code with its own attributes would be in another file, compiled by a completely different flow, foreign to the main application source code. So, no possible conflicts between this different files.
That said, if you are worried by these attributes, my goal for the next version of SYCL is to avoid all these attributes by just relying on non-attribute pure C++ constructs, when possible.

[AlexeySachkov]

I think can be closed as answered: SYCL & OpenCL can be used together, there is a corresponding section about interoperability in the SYCL spec. However, we don't have a conflict of attributes spelling and semantics, because in OpenCL device programs are written in OpenCL C in a separate file