Skip to content

Conversation

@KornevNikita
Copy link
Contributor

@KornevNikita KornevNikita commented Apr 2, 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)

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)
@KornevNikita KornevNikita marked this pull request as ready for review April 2, 2025 19:28
@KornevNikita KornevNikita requested a review from a team as a code owner April 2, 2025 19:28
@AlexeySachkov AlexeySachkov merged commit d92787a into sycl-rel-6_1_0 Apr 3, 2025
5 of 16 checks passed
@KornevNikita KornevNikita deleted the cherry-pick-1cd73d96798ed0bebc291457d334c8b34de8ea7a branch April 3, 2025 14:23
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.

4 participants