Single-pass scan kernel template

[adamfidel]

This PR provides an implementation of the single-pass scan algorithm as a kernel template.

[dmitriy-sobolev]

I've left some minor comments.
Meanwhile, I'm looking at the kernel internals and will be back with the comments soon if any.

[akukanov]

Is this for the same problem as the macro right above (which is also documented as a known issue), or for a different one?

[adamfidel]

I thought it was a different problem, but looking at it more, I think it's the same issue that the macros _PSTL_ICPX_TEST_RED_BY_SEG_BROKEN_64BIT_TYPES and ONEDPL_WORKAROUND_FOR_IGPU_64BIT_REDUCTION are meant for.

I know the internal ticket number for this issue, but it's hard to correlate that this is the same issue that these other macros are for because we do not (rightfully so) associate our internal issue tracking with these comments.

[adamfidel]

After an offline discussion with @mmichel11, we found that _PSTL_ICPX_TEST_RED_BY_SEG_BROKEN_64BIT_TYPES is for a separate issue.

The macro ONEDPL_WORKAROUND_FOR_IGPU_64BIT_REDUCTION seems to be from the same root issue, but I feel that we should still use a separate macro for the following reasons:

1. The ONEDPL_WORKAROUND_FOR_IGPU_64BIT_REDUCTION macro is expected to be defined externally through CMake rather than defined in test_config.h with the other macros
2. The macro's name suggests that when defined, it will apply some workaround for 64-bit group reductions with multiplies, whereas in this case, we want to explictly disable the tests cases with 64-bit types and the std::multiplies binary operator

[dmitriy-sobolev]

I've checked everything besides atomics, especially the specifics of the used memory ordering. Everything what I've checked looks good to me.

[danhoeflinger]

This LGTM. I checked it far more thoroughly earlier on, but I have been reviewing delta commits and following the comments, and they look good to me.

My outstanding issues have been:

1. init value, which we have decided to address in a later PR
2. Memory footprint in SLM of joint algorithms, and how to communicate memory footprint requirements to the end user to provide them the proper guidance for selecting kernel params. I think this remains somewhat unresolved (as the sycl feature is a black box), but I think we can make a GH issue, and improve on this in the future (if we feel unsatisfied with our guidance in the docs with the current code). I don't think it is worth holding back this PR for this.

It would probably be good to get another approval from one of the others who have been working on this.

[dmitriy-sobolev]

LGTM. I've reviewed the atomic operations and found no race conditions.

One more suggestions to consider doing in a separate PR: use regular (non-atomic) variables for values.

[adamfidel]

Thanks all for the reviews!

@danhoeflinger and @dmitriy-sobolev, I will create GH issues to address the next steps that you have mentioned in your approvals.