Alternative approach of working with barriers

[SergeyKopienko]

The initial issue has been detected and investigated by @dmitriy-sobolev in the PR #2054

This PR simple make the fit for that issue by a little bit another way.

[mmichel11]

I think the problem with this approach is that sycl::access::fence_space is not a part of SYCL2020 at all, so we cannot expect a compiler to implement it.

[SergeyKopienko]

I think it's simple not documented now, but not deprecated too.
And we haven't any warnings about that.

[SergeyKopienko]

Practically we are using this enum in oneDPL code in main branch too, but only in one place:

template <typename _Item>
constexpr void
__group_barrier(_Item __item)
{
#if 0 // !defined(_ONEDPL_LIBSYCL_VERSION) || _ONEDPL_LIBSYCL_VERSION >= 50300
    //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
    sycl::group_barrier(__item.get_group(), sycl::memory_scope::work_group);
#else
    __item.barrier(sycl::access::fence_space::local_space);  // <<<<<<<<<<<<< HERE
#endif
}

[mmichel11]

I see, so I guess the current state is probably not compatible with non-dpcpp SYCL compilers unless they also have this SYCL 1.2.1 support.

[SergeyKopienko]

May be. But in any case, we are not making anything worse at this place.

[SergeyKopienko]

As far as I understood this implementation is not preferable, so I close the PR.