[SYCL][AOT] Define CL_TARGET_OPENCL_VERSION to OpenCL 2.2

[fwyzard]

When using the Khronos OpenCL headers from GitHub, set the preprocessor
symbol CL_TARGET_OPENCL_VERSION=220 to silence the compilation warning
from the OpenCL header files, and define all OpenCL 2.2 symbols.

Include the OpenCL headers through CL/sycl/detail/cl.h, and define
the CL_TARGET_OPENCL_VERSION to 220 (OpenCL 2.2) by default.

Protect the use of OpenCL 2.0 and 2.2 symbols with the relevant #ifdef.

[fwyzard]

Fixes #1607.

[dm-vodopyanov]

LGTM

[smaslov-intel]

What will it be if someone continues to include <CL/cl.h> or <CL/opencl.h> directly? Will we just see the warning again? Can we somehow guard from doing this? Maybe add an error directive into some common SYCL header to check that CL_TARGET_OPENCL_VERSION is defined when CL is included/defined (there should be something robust to reflect that I believe),

[bader]

What will it be if someone continues to include <CL/cl.h> or <CL/opencl.h> directly? Will we just see the warning again? Can we somehow guard from doing this? Maybe add an error directive into some common SYCL header to check that CL_TARGET_OPENCL_VERSION is defined when CL is included/defined (there should be something robust to reflect that I believe),

IIRC, it's not a warning - it's a remark.

[bader]

It's a "pragma message" - https://github.com/KhronosGroup/OpenCL-Headers/blob/master/CL/cl_version.h#L22

[bader]

LGTM.
A few nits.

[smaslov-intel]

What will it be if someone continues to include <CL/cl.h> or <CL/opencl.h> directly? Will we just see the warning again? Can we somehow guard from doing this? Maybe add an error directive into some common SYCL header to check that CL_TARGET_OPENCL_VERSION is defined when CL is included/defined (there should be something robust to reflect that I believe),

IIRC, it's not a warning - it's a remark.

OK, but the point is that can we make something to get an error instead?

[fwyzard]

What will it be if someone continues to include <CL/cl.h> or <CL/opencl.h> directly? Will we just see the warning again?

Actually, I don't think we would see anything during the build, because CMake now does define CL_TARGET_OPENCL_VERSION.
The message could potentially happen in some user's code that includes the SYCL header.

Can we somehow guard from doing this? Maybe add an error directive into some common SYCL header to check that CL_TARGET_OPENCL_VERSION is defined when CL is included/defined

Mhm... the most robust thing I can think of would be to patch the version of CL/cl_version.h to replace the #pragma message with an #error - but I don't think this change should be included in the version that is installed.

An other possibility could be some check like

#if defined __CL_VERSION_H && ! defined CL_TARGET_OPENCL_VERSION
#error Do not include <CL/cl.h> or <CL/opencl.h> directly, use <CL/sycl/detail/cl.h> instead
#endif

but I have no idea how one could apply to all relevant cpp files.

[fwyzard]

One of the check fails with

The following symbols are missing from the new object file:
_ZN2cl4sycl7handler15addEventToQueueESt10shared_ptrINS0_6detail10queue_implEENS0_5eventE
error: command failed with exit status: 255

but in fact I can't find any reference to it - maybe it's related to #1622 ?

[fwyzard]

I've reverted the opencl-aot code changes.
Could you retrigger the checks ?

[fwyzard]

@bader could you trigger the Lit_With_Cuda test ?