-
Notifications
You must be signed in to change notification settings - Fork 789
[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
[SYCL] Fix the type trait 'known_identity' #3227
Conversation
- 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]>
This patch only fixes a correctness problem caused by using vec<int,N> types. |
There was a problem hiding this 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< |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
It might make sense to only support marray instead of vec and make sure that marray is constexpr. |
Now SYCL 2020 is out we have more time to But I have the feeling that adding some I was about creating an issue about it but discovered I already created one... https://gitlab.khronos.org/sycl/Specification/-/issues/246 Ahem... :-/ |
Signed-off-by: Vyacheslav N Klochkov <[email protected]>
Signed-off-by: Vyacheslav N Klochkov <[email protected]>
572e590
to
389fe9b
Compare
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! |
There was a problem hiding this 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 | |||
|
There was a problem hiding this comment.
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.
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. |
…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]>
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]>
like sycl::int4 as a reduction variable.
Signed-off-by: Vyacheslav N Klochkov [email protected]