Remove support of old compilers from oneDPL code

[SergeyKopienko]

As far as our supported compiler is 2022.2.0 (int's started from Intel oneAPI 2022.3), we able to remove the code for older compilers.

For 2022.2.0, the _ONEDPL_LIBSYCL_VERSION is equal to 50700.

This mean that all comparison of _ONEDPL_LIBSYCL_VERSION with 50700 or some less values not required anymore.
So in this PR we removes the next parts of code:

• _ONEDPL_LIBSYCL_VERSION >= 50200
• _ONEDPL_LIBSYCL_VERSION >= 50300
• _ONEDPL_LIBSYCL_VERSION >= 50400
• _ONEDPL_LIBSYCL_VERSION >= 50700

Also we add minimal compiler version check here :

// Combine SYCL runtime library version
#if defined(__LIBSYCL_MAJOR_VERSION) && defined(__LIBSYCL_MINOR_VERSION) && defined(__LIBSYCL_PATCH_VERSION)
#    define _ONEDPL_LIBSYCL_VERSION                                                                                    \
       (__LIBSYCL_MAJOR_VERSION * 10000 + __LIBSYCL_MINOR_VERSION * 100 + __LIBSYCL_PATCH_VERSION)
#    if _ONEDPL_LIBSYCL_VERSION < 57000
#        error "oneDPL requires Intel(R) oneAPI DPC++/C++ Compiler 2022.2.0 or newer"
#    endif
#else
#    define _ONEDPL_LIBSYCL_VERSION 0
#endif

For check macros state please take a look at https://godbolt.org/z/ne1z7n36b :

• for icx 2022.2.0 the state of macros is:

__LIBSYCL_MAJOR_VERSION = 5
__LIBSYCL_MINOR_VERSION = 7
__LIBSYCL_PATCH_VERSION = 0

[SergeyKopienko]

@MikeDvorskiy what we should to do with this #if 0 ?

[MikeDvorskiy]

 //TODO: usage of sycl::group_barrier: probably, we have to revise SYCL parallel patterns which use a group_barrier.
// 1) sycl::group_barrier() implementation is not ready
// 2) sycl::group_barrier and sycl::item::group_barrier are not quite equivalent

[MikeDvorskiy]

sycl::group_barrier() did not work at that moment.
I think you should double check the semantic and if it equivalent, figure out from which SYCL library version sycl::group_barrier() is ready and work properly.

[SergeyKopienko]

@MikeDvorskiy, could you please explain, what exactly did not work and in which cases?

[SergeyKopienko]

Issue created: #1679
let's fix it in the separate PR later.

[danhoeflinger]

Just generally... does it make sense to "break" all compiles outside of our supported compilers, or merely "warn" that they may not work properly?

The way I look at the support compilers is that these are the compilers we must support and are committed to fixing issue with, rather than these are the only compilers we allow to use the library.

From that perspective, I would argue we should only make changes to explicitly remove support if it benefits us in some specific way (even if that specific way is merely that it makes the code significantly easier to maintain).

I haven't yet investigated all the individual changes of the PR, but it seems to me we shouldn't go out of our way to stop people from using the code with an out of date compiler. If we do decide to have such an error, I would recommend we also add a deprecation-style warning for compilers which are about to leave our window of support in the next 6-12 months.