Make SYCL backend detection more portable

[dmitriy-sobolev]

SYCL specification allows SYCL to be implemented purely as a library: https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#_library_only_implementation. It means that inclusion of sycl/sycl.hpp is a portable way to get SYCL_LANGUAGE_VERSION, in contrast to expecting it to be defined by the compiler itself. Additionally, AdaptiveCPP defines this macro in sycl/sycl.hpp.

[danhoeflinger]

I have a memory of us running into issues with some compilers providing sycl.hpp, but not actually providing a working SYCL implementation when we were adding this to CMake detection of the availability of SYCL. Wouldn't this have the potential for some problems in that case?

My memory is that this was with clang++, but I may be mistaken. Let me see if I can pull up that discussion.

[danhoeflinger]

I have a memory of us running into issues with some compilers providing sycl.hpp, but not actually providing a working SYCL implementation when we were adding this to CMake detection of the availability of SYCL. Wouldn't this have the potential for some problems in that case?

My memory is that this was with clang++, but I may be mistaken. Let me see if I can pull up that discussion.

It turns out its the opposite issue in reality #959 (comment)
fsycl option was available but headers not available.

[akukanov]

Let's do some analysis first.

__ONEDPL_SYCL_AVAILABLE expectedly says whether it is possible to use SYCL code. It is then used to
a) check SYCL availability when it is requested via ONEDPL_USE_DPCPP_BACKEND
b) enable SYCL backend implicitly when not requested

There are two SYCL availability tests we use:

1. check if <sycl/sycl.hpp> is accessible
2. check if SYCL_LANGUAGE_VERSION is defined.

According to the SYCL standard, eventually both checks need to pass.
(1) is a mandatory condition prior for any use of SYCL, while (2) might depend on the implementation, as Dmitriy points out.
For some compilers, including DPC++, (2) is independently enabled by a compiler option.
For other compilers or library only implementations, (2) might never be true until the header is included. However even after the header is included, (2) is not always true I think, and so it still needs to be checked.

So the simplest generic SYCL availability test would be:

1. check if <sycl/sycl.hpp> is accessible
   1.5) include <sycl/sycl.hpp>
2. check if SYCL_LANGUAGE_VERSION is defined

However, we do not want to include the SYCL header until it's needed. Also, if the header code depends on compiler support,
including it without prior checking (2) might in theory cause errors. So an intermediate state "SYCL is possibly available" - which essentially means we observe the header but not the language macro - seems useful.

Also note that the use cases (a) and (b) would treat "possibly available" differently:

• if the use of SYCL is explicitly requested, i.e. ONEDPL_USE_DPCPP_BACKEND is set to a non-zero value,
  we may assume that the environment is ready for that, and including the header seems reasonable.
• if there was no direct request for SYCL, we need to be cautious and should not include the header
  unless we are sure it will not cause errors.

The general procedure could be:

1. check if <sycl/sycl.hpp> is accessible;
   • if no, SYCL is definitely not available.
2. check if SYCL_LANGUAGE_VERSION is defined;
   • if yes, SYCL is definitely available.
   • if no, but we know it is required (as for Intel Compiler), SYCL is definitely not available.
   • otherwise, SYCL is possibly available
3. Case (a): if the use of SYCL is requested but SYCL is definitely not available, issue an error.
4. If the use of SYCL is requested and SYCL is [possibly] available (i.e. not definitely unavailable), enable the SYCL backend.
5. Case (b): If the use of SYCL is not requested but we are sure including the header is safe, enable the SYCL backend.
   • Currently, we are only sure when SYCL is definitely available, but we can expand it later for "known good" environments.

With this procedure, the SYCL backend might be enabled without requiring SYCL_LANGUAGE_VERSION a priori,
and therefore the backend should check SYCL_LANGUAGE_VERSION after including the header:

6. include <sycl/sycl.hpp>
7. if SYCL_LANGUAGE_VERSION is still not defined:
   • complete the case (a): if SYCL was requested, issue an error.
   • disable the SYCL backend and skip the rest of it.
   • alternatively, if disabling the SYCL backend from inside does not seem feasible, just issue an error.

[dmitriy-sobolev]

Thank you for such a detailed analysis, Alexey. I've implemented this suggestion.

[akukanov]

I have some questions and suggestions.

Also, there is no check in the backend that the language version macro is properly defined after the header is included.

[akukanov]

It looks good to me.

[danhoeflinger]

LGTM, these are all good changes. If you want to take the optional nitpicks, I will approve after

[danhoeflinger]

LGTM, the clang format suggestion is bad and should be ignored.