-
Notifications
You must be signed in to change notification settings - Fork 72
Allow "std::byte" as "vec" element type #674
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
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is change 7 of 9 that fix problems with the specification of the `vec` class. An implementation that follows the existing specification would not accept common code patterns and would not pass the CTS. None of the existing implementations actually follow the existing specification. This change clarifies that `std::byte` is a legal element type for `vec`. This is one possible interpretation of the previous wording where we said that the element data type must be a "basic scalar type". We think that phrase included `sycl::byte`. However, `sycl::byte` was deprecated in SYCL 2020 saying that `std::byte` is a replacement. If we allow `std::byte`, we need to adjust the constraints for the various `vec` operators. We decided to allow these operators on `vec` of `std::byte`, which mostly follows the C++ rules for operators on plain `std::byte`: * Comparison: ==, !=, <, <=, >, >= * Bitwise: &, |, ^, ~, &=, |=, ^= I decided it was clearer to rephrase the constraints to say which types are allowed rather than listing the types that are not allowed. For example, this results in phrasing like: > Available only when DataT is an integral type. Rather than: > Available only when: DataT != float && DataT != double && > DataT != half && DataT != std::byte. These changes correspond to slide 26 of the presentation that was discussed in the WG meetings.
keryell
approved these changes
Jan 9, 2025
Member
keryell
left a comment
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.
Thanks for the generalization.
nliber
approved these changes
Feb 6, 2025
aelovikov-intel
added a commit
to aelovikov-intel/SYCL-CTS
that referenced
this pull request
Feb 26, 2025
Spec changes are at KhronosGroup/SYCL-Docs#674.
aelovikov-intel
added a commit
to aelovikov-intel/SYCL-CTS
that referenced
this pull request
Feb 26, 2025
Spec changes are at KhronosGroup/SYCL-Docs#674.
Contributor
Author
|
CTS tests added in KhronosGroup/SYCL-CTS#1058 |
aelovikov-intel
added a commit
to aelovikov-intel/llvm
that referenced
this pull request
Mar 31, 2025
KhronosGroup/SYCL-Docs#670 Technically, we also implement part of KhronosGroup/SYCL-Docs#674 (`std::byte` as element type) here, but there is no reasonable way to make them completely independent. This is built on top of intel#17712 and intel#17713. With these three pieces in place we can keep building CTS successfully, so enable this new implementation (via `__SYCL_USE_PREVIEW_VEC_IMPL`) automatically under `-fpreview-breaking-changes` mode.
aelovikov-intel
added a commit
to intel/llvm
that referenced
this pull request
Apr 2, 2025
Implements KhronosGroup/SYCL-Docs#670. Technically, we also implement part of KhronosGroup/SYCL-Docs#674 (`std::byte` as element type) here, but there is no reasonable way to make them completely independent. This is built on top of #17712 and #17713.
Contributor
|
KhronosGroup/SYCL-CTS#1058 CTS now merged |
Contributor
|
WG approved to merge |
gmlueck
added a commit
to gmlueck/SYCL-Docs
that referenced
this pull request
May 22, 2025
Cherry pick KhronosGroup#674 from main (cherry picked from commit ee2b2f8)
carbotaniuman
pushed a commit
to carbotaniuman/SYCL-CTS
that referenced
this pull request
Aug 4, 2025
Spec changes are at KhronosGroup/SYCL-Docs#674.
carbotaniuman
pushed a commit
to carbotaniuman/SYCL-CTS
that referenced
this pull request
Aug 4, 2025
Spec changes are at KhronosGroup/SYCL-Docs#674.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is change 7 of 9 that fix problems with the specification of the
vecclass. An implementation that follows the existing specification would not accept common code patterns and would not pass the CTS. None of the existing implementations actually follow the existing specification.This change clarifies that
std::byteis a legal element type forvec. This is one possible interpretation of the previous wording where we said that the element data type must be a "basic scalar type". We think that phrase includedsycl::byte. However,sycl::bytewas deprecated in SYCL 2020 saying thatstd::byteis a replacement.If we allow
std::byte, we need to adjust the constraints for the variousvecoperators. We decided to allow these operators onvecofstd::byte, which mostly follows the C++ rules for operators on plainstd::byte:I decided it was clearer to rephrase the constraints to say which types are allowed rather than listing the types that are not allowed. For example, this results in phrasing like:
Rather than:
These changes correspond to slide 26 of the presentation that was discussed in the WG meetings.