oneDPL
oneDPL copied to clipboard
oneapi-src
Do not use internal API in the tests
Do not rely on functionality from oneapi/dpl/pstl/hetero/dpcpp/sycl_defs.h.
Signed-off-by: Sobolev, Dmitriy [email protected]
what is the purpose of this patch? You are saying about different versions on oneDPL but I don't understand the use-case. Are trying to do not use sycl_defs as public API in tests and this is good but I don't understand what problem we are trying to solve, sorry.
what is the purpose of this patch? You are saying about different versions on oneDPL but I don't understand the use-case. Are trying to do not use sycl_defs as public API in tests and this is good but I don't understand what problem we are trying to solve, sorry.
@rarutyun, this is a case when the tests are used with newer library headers. This can be treated as a backward compatibility testing. If there is no dependency on internal APIs from the library headers, then such testing is possible.
@akukanov, @dmitriy-sobolev but what about https://github.com/oneapi-src/oneDPL/pull/937 ?
I mean __dpl_sycl::__get_host_access in the tests.
Looks like it should be fixed too.
I the tests for permutation iterator I just copied data to host and checked it's state.
@akukanov, @dmitriy-sobolev but what about #937 ? I mean
__dpl_sycl::__get_host_accessin the tests. Looks like it should be fixed too. I the tests for permutation iterator I just copied data to host and checked it's state.
This PR is based on old commits, so there are a lot of new cases of using of internal APIs. We can either merge it as is and do the second PR, or rebase it and finish the work here. I am inclined towards the second option.
@akukanov, @dmitriy-sobolev but what about #937 ? I mean
__dpl_sycl::__get_host_accessin the tests. Looks like it should be fixed too. I the tests for permutation iterator I just copied data to host and checked it's state.This PR is based on old commits, so there are a lot of new cases of using of internal APIs. We can either merge it as is and do the second PR, or rebase it and finish the work here. I am inclined towards the second option.
@SergeyKopienko, thanks for pointing that PR, though. It was a single occurrence of using internal __sycl_defs entities besides the ones which had been fixed.
I've found much more cases of using other internal APIs (non-sycl ones). There is abundant amount of them: searching for "internal" in the test folder results in ~250 cases across ~40 files. Cleaning it up feels like another task, I will create an issue.
@SergeyKopienko and @akukanov, could you take a look at the PR once again?