Incorrect Kernel name generation for __parallel_reduce_then_scan_reduce_submitter and for __parallel_reduce_then_scan_scan_submitter

[SergeyKopienko]

In this PR we fixing the issue #2139

Previously we had next Kernel names generation for these structures:

    using _CustomName = oneapi::dpl::__internal::__policy_kernel_name<_ExecutionPolicy>;
    using _ReduceKernel = oneapi::dpl::__par_backend_hetero::__internal::__kernel_name_provider<
        __reduce_then_scan_reduce_kernel<_CustomName>>;
    using _ScanKernel = oneapi::dpl::__par_backend_hetero::__internal::__kernel_name_provider<
        __reduce_then_scan_scan_kernel<_CustomName>>;

It's not enough to describe all possible instantiations of struct __parallel_reduce_then_scan_reduce_submitter, struct __parallel_reduce_then_scan_scan_submitter and their operator() instantiations.

[SergeyKopienko]

@mmichel11, should we also include this fix into already released version of oneDPL ?

[SergeyKopienko]

Probably this issue has been introduced in the PR #2046

[danhoeflinger]

Why do we need kernel name generator for this case (rather than kernel name provider)?

If someone passes in a policy with the same external kernel name in to two different oneDPL API invocations then its their error not ours, right?

[SergeyKopienko]

@danhoeflinger Please just find in the code how _ReduceKernel and _ScanKerne later used. They passed into parallel_for as Kernel names without any changes.

[danhoeflinger]

@danhoeflinger Please just find in the code how _ReduceKernel and _ScanKerne later used. They passed into parallel_for as Kernel names without any changes.

OK, so why is that a problem?
We separate the reduce and scan kernels using different wrappers on the user provided custom name.

Lets go through the options:

1. A user provides a unique kernel name, and unnamed lambdas are permitted: Works
2. A user provides a unique kernel name, and unnamed lambdas are NOT permitted: Works
3. A user uses default policy name, and unnamed lambdas are permitted: Works, because __kernel_name_provider uses __optional_kernel_name<>, and then the submitters partially specialize to get _KernelName... pack, and provide that to the kernel, where it is an empty pack, so it uses an unnamed lambda
4. A user uses the default policy name and unnamed lambda are NOT permitted: Fails, (correctly) because it is the user's responsibility to provide a unique kernel name to the policy for each call when using no-unamed-lambdas.
5. A user uses the same custom named policy for two oneDPL API calls: Fails, (correctly) because if custom names are provided they must be unique for each call.

Are there any other options, or any options which you disagree with the expected outcome?

[danhoeflinger]

To clarify an often missed but important thing:
__kernel_name_generator is specifically for kernels for which we need to use a kernel bundle to first compile the kernel, then query something about the result of the kernel compilation, like to get the exact workgroup size or something to size buffers, etc.

I think its used in the old scan, radix sort, reduce and by-segment algs.

[SergeyKopienko]

It's not a bug: it's by design.