[SYCL] Switch to use plain array in sycl::vec in more cases
#17656
Conversation
This file contains 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
The problem with using `std::array` in `sycl::vec` is that we cannot compile it in some environments (namely, Windows) because the former may use something that is illegal in SYCL device code. intel#17025 fixed that, but only did so under preview breaking changes mode, which does not satisfy some of our customers immediately. This PR introduces two main changes: - it allows to opt-in for new behavior through passing `-D__SYCL_USE_NEW_VEC_IMPL=1` macro without using `-fpreview-breaking-changes` flag. That allows for a more gradual opt-in from customers who are interested in this fix - it switches the imlpementation to use the new approach with C-style arrays if their size and alignment is the same as for the corresponding `std::array` - in that case their memory layout is expected to be absolutely the same and therefore it should be safe to use the new approach without fear of some ABI incompatibilities. This allows for customers to benefit from the fix without specifying any extra macro (which should be the case for the most common platforms out there)
AlexeySachkov
had a problem deploying
to
WindowsCILock
GitHub Actions
Failure
AlexeySachkov
had a problem deploying
to
WindowsCILock
GitHub Actions
Error
AlexeySachkov
had a problem deploying
to
WindowsCILock
GitHub Actions
Error
AlexeySachkov
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
AlexeySachkov
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
AlexeySachkov
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
sycl/include/sycl/vector.hpp
Outdated
| // alignment match those of std::array, or unless the new behavior is forced | ||
| // via __SYCL_USE_NEW_VEC_IMPL or preview breaking changes mode. | ||
| using DataType = std::conditional_t< | ||
| #if __SYCL_USE_NEW_VEC_IMPL |
There was a problem hiding this comment.
FYI, I think @aelovikov-intel is also using this flag for some other (draft?) sycl::vec refactoring work. So, if the user explicitly specifies __SYCL_USE_NEW_VEC_IMPL macro, it might bring in Andrei's changes as well, along with the switch to using C-arrays.
There was a problem hiding this comment.
The main point here is to have some sort of opt-in mechanism for customers who value building in debug mode on windows using clang.exe (instead of clang-cl.exe) over backwards compatibility or potential ABI issues. So, I'm fine with choosing any other name here, I've just re-used what we had already
There was a problem hiding this comment.
True. Let's use some other macro name
There was a problem hiding this comment.
Done in 0c1c53d
AlexeySachkov
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
steffenlarsen
approved these changes
Mar 27, 2025
AlexeySachkov
had a problem deploying
to
WindowsCILock
GitHub Actions
Error
AlexeySachkov
had a problem deploying
to
WindowsCILock
GitHub Actions
Error
AlexeySachkov
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
AlexeySachkov
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
AlexeySachkov
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
There was a problem hiding this comment.
Can anybody find one widely used configuration (gcc/clang/msvc) where that's not true? If not, just make the change unconditionally and be done with it. We're doing shadier things all the time, no need to pretend to be so proper here, IMO.
PS, sycl::vec's alignment is much stricter than that of std::array, see line 195. I don't think your alignment check is necessary.
AlexeySachkov
deleted the
private/asachkov/switch-to-plain-array-in-vec-earlier
branch
AlexeySachkov
added a commit
to AlexeySachkov/llvm
that referenced
this pull request
Mar 27, 2025
The problem with using `std::array` in `sycl::vec` is that we cannot compile it in some environments (namely, Windows) because the former may use something that is illegal in SYCL device code. intel#17025 fixed that, but only did so under preview breaking changes mode, which does not satisfy some of our customers immediately. This PR introduces two main changes: - it allows to opt-in for new behavior through passing `-D__SYCL_USE_NEW_VEC_IMPL=1` macro without using `-fpreview-breaking-changes` flag. That allows for a more gradual opt-in from customers who are interested in this fix - it switches the imlpementation to use the new approach with C-style arrays if their size and alignment is the same as for the corresponding `std::array` - in that case their memory layout is expected to be absolutely the same and therefore it should be safe to use the new approach without fear of some ABI incompatibilities. This allows for customers to benefit from the fix without specifying any extra macro (which should be the case for the most common platforms out there) This is a cherry-pick of intel#17656
AlexeySachkov
added a commit
that referenced
this pull request
Mar 31, 2025
…ses" to sycl-rel-6_0_0 (#17697) This is a cherry-pick of #17656 + changes required to resolve merge conflicts. -------------------------------------- The problem with using std::array in sycl::vec is that we cannot compile it in some environments (namely, Windows) because the former may use something that is illegal in SYCL device code. #17025 fixed that, but only did so under preview breaking changes mode, which does not satisfy some of our customers immediately. This PR introduces two main changes: it allows to opt-in for new behavior through passing -D__SYCL_USE_NEW_VEC_IMPL=1 macro without using -fpreview-breaking-changes flag. That allows for a more gradual opt-in from customers who are interested in this fix it switches the imlpementation to use the new approach with C-style arrays if their size and alignment is the same as for the corresponding std::array - in that case their memory layout is expected to be absolutely the same and therefore it should be safe to use the new approach without fear of some ABI incompatibilities. This allows for customers to benefit from the fix without specifying any extra macro (which should be the case for the most common platforms out there) --------- Co-authored-by: Alexey Sachkov <alexey.sachkov@intel.com>
KornevNikita
pushed a commit
that referenced
this pull request
Apr 2, 2025
The problem with using `std::array` in `sycl::vec` is that we cannot compile it in some environments (namely, Windows) because the former may use something that is illegal in SYCL device code. #17025 fixed that, but only did so under preview breaking changes mode, which does not satisfy some of our customers immediately. This PR introduces two main changes: - it allows to opt-in for new behavior through passing `-D__SYCL_USE_NEW_VEC_IMPL=1` macro without using `-fpreview-breaking-changes` flag. That allows for a more gradual opt-in from customers who are interested in this fix - it switches the imlpementation to use the new approach with C-style arrays if their size and alignment is the same as for the corresponding `std::array` - in that case their memory layout is expected to be absolutely the same and therefore it should be safe to use the new approach without fear of some ABI incompatibilities. This allows for customers to benefit from the fix without specifying any extra macro (which should be the case for the most common platforms out there)
AlexeySachkov
added a commit
that referenced
this pull request
Apr 3, 2025
### Cherry-pick of: #17656 and some changes to resolve merge conflicts & make it work. The problem with using `std::array` in `sycl::vec` is that we cannot compile it in some environments (namely, Windows) because the former may use something that is illegal in SYCL device code. #17025 fixed that, but only did so under preview breaking changes mode, which does not satisfy some of our customers immediately. This PR introduces two main changes: - it allows to opt-in for new behavior through passing `-D__SYCL_USE_NEW_VEC_IMPL=1` macro without using `-fpreview-breaking-changes` flag. That allows for a more gradual opt-in from customers who are interested in this fix - it switches the imlpementation to use the new approach with C-style arrays if their size and alignment is the same as for the corresponding `std::array` - in that case their memory layout is expected to be absolutely the same and therefore it should be safe to use the new approach without fear of some ABI incompatibilities. This allows for customers to benefit from the fix without specifying any extra macro (which should be the case for the most common platforms out there) Co-authored-by: Alexey Sachkov <alexey.sachkov@intel.com>
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.
The problem with using
std::arrayinsycl::vecis that we cannot compile it in some environments (namely, Windows) because the former may use something that is illegal in SYCL device code.#17025 fixed that, but only did so under preview breaking changes mode, which does not satisfy some of our customers immediately.
This PR introduces two main changes:
-D__SYCL_USE_NEW_VEC_IMPL=1macro without using-fpreview-breaking-changesflag. That allows for a more gradual opt-in from customers who are interested in this fixstd::array- in that case their memory layout is expected to be absolutely the same and therefore it should be safe to use the new approach without fear of some ABI incompatibilities. This allows for customers to benefit from the fix without specifying any extra macro (which should be the case for the most common platforms out there)