Skip to content

[SYCL] Fix the type trait 'known_identity' #3227

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Feb 26, 2021

Conversation

v-klochkov
Copy link
Contributor

@v-klochkov v-klochkov commented Feb 18, 2021

  • Copy 'known_identity' and 'has_known_identity' from sycl::ONEAPI to sycl
  • Fix the compilation errors reported on attempts to use vector types
    like sycl::int4 as a reduction variable.

Signed-off-by: Vyacheslav N Klochkov [email protected]

- Move 'known_identity' and 'has_known_identity' from sycl::ONEAPI to sycl
- Fix the compilation errors reported on attempts to use vector types
  like sycl::int4 as a reduction variable.

Signed-off-by: Vyacheslav N Klochkov <[email protected]>
@v-klochkov v-klochkov requested a review from Pennycook February 18, 2021 03:30
@v-klochkov v-klochkov requested a review from a team as a code owner February 18, 2021 03:30
@v-klochkov
Copy link
Contributor Author

This patch only fixes a correctness problem caused by using vec<int,N> types.
Potentially, known_identity< std::plus<>, int4 > could return a constexpr value, but that would require additional elaborate changes in vec class, and that is a lower priority task than the stability crash fixed in this pull request.

Copy link
Contributor

@Pennycook Pennycook left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm okay with this change as a temporary fix, but we need to revisit this issue. It's not clear to me whether has_known_identity requiring constexpr is too restrictive, or whether types like vec should be made constexpr.

The SYCL 2020 specification doesn't seem to say whether an implementation is expected to be able to determine the identity value for vector types, and it probably comes down to whether or not a vector counts as "an arithmetic type" (see https://www.khronos.org/registry/SYCL/specs/sycl-2020/html/sycl-2020.html#sec:reduction). This probably requires some clarification.

template <typename BinaryOperation, typename AccumulatorT>
struct has_known_identity : detail::has_known_identity_impl<
struct has_known_identity : ONEAPI::detail::has_known_identity_impl<
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know the answer to this, but I want to make sure that we're being consistent across different extensions and SYCL 2020 features. Should this be available as ONEAPI::has_known_identity in SYCL 1.2.1 mode, and only available as has_known_identity in SYCL 2020 mode?

Copy link
Contributor Author

@v-klochkov v-klochkov Feb 23, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

only available as has_known_identity in SYCL 2020 mode

John, I tried implementing what you suggested in 9b355ef and 389fe9b
When you say "only in SYCL 2020 mode" what do you mean?
I don't see good ways to enable it only for SYCL-2020. In my opinion, sycl::has_known_identity should be available by default in headers as SYCL-2020 seems to be the default now with -fsycl. Guarding sycl::has_known_identity with some macros like SYCL_LANGUAGE_VERSION >= 202001L seems not very usable as it would break compilation of SYCL-2020 programs without using -fsycl switch.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was assuming that we would still allow developers to request SYCL 1.2.1 -- if that isn't the case, then I'm less worried about conditionally enabling SYCL 2020 features.

That said, I think standard C++ headers typically guard features based on the standard that included them. I don't feel strongly about this -- @rolandschulz, do you think it matters at all?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we don't (partially) support multiple SYCL versions, I don't see a reason to have features guarded.

@rolandschulz
Copy link
Contributor

I'm okay with this change as a temporary fix, but we need to revisit this issue. It's not clear to me whether has_known_identity requiring constexpr is too restrictive, or whether types like vec should be made constexpr.

It might make sense to only support marray instead of vec and make sure that marray is constexpr.

@keryell
Copy link
Contributor

keryell commented Feb 18, 2021

Now SYCL 2020 is out we have more time to constexpr-ify the specification.

But I have the feeling that adding some constexpr today in an implementation should not change the compliance test and would make the implementation better, exposing more optimization opportunities.

I was about creating an issue about it but discovered I already created one... https://gitlab.khronos.org/sycl/Specification/-/issues/246 Ahem... :-/

@v-klochkov v-klochkov force-pushed the public_vklochkov_reduction_int4 branch from 572e590 to 389fe9b Compare February 23, 2021 21:15
@v-klochkov v-klochkov requested a review from Pennycook February 26, 2021 15:00
@smaslov-intel
Copy link
Contributor

Move 'known_identity' and 'has_known_identity' from sycl::ONEAPI to sycl

Isn't this is a backward compatibility breaking change that we aren't allowed to do except in major releases?

@v-klochkov
Copy link
Contributor Author

v-klochkov commented Feb 26, 2021

Move 'known_identity' and 'has_known_identity' from sycl::ONEAPI to sycl

Isn't this is a backward compatibility breaking change that we aren't allowed to do except in major releases?

The later commit 9b355ef in this PR puts it back to sycl::ONEAPI. I replaced the word 'move' with the word 'copy' in the description. Thank you!

Copy link
Contributor

@smaslov-intel smaslov-intel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, just minor ask for a TODO comment to remember to remove the ONEAPI copy.

@@ -1659,7 +1642,30 @@ template <typename BinaryOperation, typename AccumulatorT>
inline constexpr AccumulatorT known_identity_v =
known_identity<BinaryOperation, AccumulatorT>::value;
#endif

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is worth to mark the code that we want to remove when allowed to break API.

@v-klochkov v-klochkov merged commit 060fd50 into intel:sycl Feb 26, 2021
@v-klochkov
Copy link
Contributor Author

for a TODO comment to remember to remove the ONEAPI

ONEAPI::has_known_identity should live as long as ONEAPI::reduction() lives.

sycl::has_known_identity will migrate from the file CL/sycl/ONEAPI/reduction.hpp to CL/sycl/reduction.hpp as soon as SYCL-2020 reductions works start, and it will be tied to sycl::reduction.

@v-klochkov v-klochkov deleted the public_vklochkov_reduction_int4 branch February 26, 2021 18:23
v-klochkov added a commit to v-klochkov/llvm that referenced this pull request May 15, 2021
…tel#3227)

The check added in (intel#3227) was supposed to return true for int32/int64,
but wrongly checked the type sizes in bits instead of bytes,
which prohibited usage of group ADD algorithm for int32/int64 in reductions.
Fixed in this patch.

Signed-off-by: Vyacheslav N Klochkov <[email protected]>
bader pushed a commit that referenced this pull request May 15, 2021
The check added in (#3227) was supposed to return true for int32/int64,
but wrongly checked the type sizes in bits instead of bytes,
which prohibited usage of group ADD algorithm for int32/int64 in reductions.

Signed-off-by: Vyacheslav N Klochkov <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants