MikeDvorskiy
MikeDvorskiy
Ok. So, the issue should be closed.
Hello, @upsj! For a "kernel fusion" we would recommend to use range API, for that case, `views::transform` as a range pipeline argument for an output range... For details, see https://oneapi-src.github.io/oneDPL/parallel_api/range_based_api.html...
Usage of `is_base_of ` instead of `is_same` in shift_left_right.pass.cpp file - yes, it makes sense. Regarding `struct next_to_last` - I don't see a sense, due to we have got no...
Alexey, I think the changes you mean (in CMakeLists.txt) should not be aligned with LLVM upstream. The "pseudo-standard" headers include/algorithm are not up-streamed/sync to LLVM repo.
I there any performance measurement after that re-writing? It would be very interesting to have a look.
Christopher, I approved CI check. First, please care about our format style (we used clang-format with an option file - see https://github.com/oneapi-src/oneDPL/blob/main/.clang-format). Also I would propose to split so huge...
> Only C++11 CI tasks are failed now - it's ok because we don't support C++11 and C++14 anymore in oneDPL : > > * https://github.com/oneapi-src/oneDPL/actions/runs/3143407787/jobs/5108115427 > * https://github.com/oneapi-src/oneDPL/actions/runs/3143407787/jobs/5108115824 In...
> > I believe that we dont need up to 90% of these changes. Because a `transform_if` semantic is trivially implementing by a call `transform` algorithm with composition a passed...
> For `transform_if`, we don't need `read` access for our output range Just "write" means read as well. I clarified it some time ago... Dont remember which way... probably, SYCL...
Probably, it makes sense to use dpl::for_each + zip(data1, data2, res) + functor with predicate? In that case we have just one access mode for all sequencies - read_write.