Dan Hoeflinger

After rebasing with current main, it seems the failure for windows-2019, cl and tbb is no longer there. I think we can go ahead and re-review the PR and consider...

@SergeyKopienko (since you have left feedback already) and others: I plan to merge ~April 16th with the existing approval if there are no objections.

Thanks all for the reviews. With merging with the existing approvals.

Interestingly, there originally was a regression (~10%) in scan performance by using the **last** subgroup, **last** workitem of the subgroup and originating a broadcast from the **last** workitem of the...

I suggest prioritizing #1762 and #1763 over this PR for now. If those go through, the performance of the oneDPL main copy_if API will supersede this KT. If we see...

At this point, I think this PR is more difficult to land in 2022.7.0 than the first two `reduce_then_scan` PRs, and provides worse performance, so I'm pulling this from the...

> My proposal: > > * remove `__future` usage on all internal levels at all and use it only in async algorithm implementations (idea of @akukanov) - this approach implemented...

@SergeyKopienko I'll try to incorporate your proposals into the RFC today as options.

> * I think this problem is potential, but it's absent right now. At least, for `result` data types. Also independently of used staff we may to think about alignment...

> Our documentation only makes mention of the case where we use a `sycl::usm_allocator` with `sycl::usm::alloc::shared`, but should we also provide a specialization for `sycl::usm_allocator` with `sycl::usm::alloc::host` to be passed...