Repository navigation
Drop __LIBSYCL_MAJOR_VERSION checks dead with the 2026.0 minimum compiler - #3174
Merged
Merged
Conversation
With DPC++ 2026.0 or newer (libsycl 9), the __LIBSYCL_MAJOR_VERSION < 7 term in needs_workaround is always false and USE_GROUP_LOAD_STORE is always 1. Its 0 fallback calls sycl::sub_group member load/store, which DPC++ 2026.2 no longer has, so the macro and the fallback are removed.
antonwolfy
requested review from
ndgrigorian and
vlad-perevezentsev
as code owners
November 8, 2026 17:57
Contributor
|
Array API standard conformance tests for dpnp=0.22.0dev1=np2py314h8d9cdd5_8 ran successfully. |
Contributor
|
View rendered docs @ https://intelpython.github.io/dpnp/index.html |
Collaborator
There was a problem hiding this comment.
🟢 Approval recommended
No active review issues block the removal of obsolete libsycl compatibility branches.
No open issues 🎉
What changed in this PR
Removes obsolete libsycl compatibility branches from libtensor headers now that DPC++ 2026.0 is the minimum supported compiler, preserving the default build behavior.
Changes:
- Makes subgroup loads and stores always use the group-load/store extension.
- Removes the legacy boolean logical-or reduction workaround while retaining the 64-bit multiplication exclusion.
- Documents removal of the shipped
USE_GROUP_LOAD_STOREmacro.
| File | Description |
|---|---|
dpnp/libtensor/include/utils/sycl_utils.hpp |
Removes the load/store selection macro and legacy fallback paths. |
dpnp/libtensor/include/kernels/reductions.hpp |
Simplifies reduction workaround selection by dropping the obsolete version check. |
CHANGELOG.md |
Records the macro removal and compiler compatibility rationale. |
Review effort: Balanced
github-actions Bot
added a commit
that referenced
this pull request
Nov 8, 2026
…mpiler (#3174) DPC++ 2026.0 is the minimum compiler (the conda recipes reject anything older), and every 2026.x release ships libsycl 9 (`__LIBSYCL_MAJOR_VERSION 9`). Two `__LIBSYCL_MAJOR_VERSION` checks in the libtensor headers therefore always take the same branch. This PR: - drops the `__LIBSYCL_MAJOR_VERSION < 7` term from `needs_workaround` in `kernels/reductions.hpp`, which kept `sycl::logical_or<bool>` off reduce-over-group for older compilers. The term is always false; the `int64`/`uint64` `sycl::multiplies` exclusion stays. - removes `USE_GROUP_LOAD_STORE` from `utils/sycl_utils.hpp`, so `sub_group_load` and `sub_group_store` always use `group_load`/`group_store` from `sycl_ext_oneapi_group_load_store`. The `__LIBSYCL_MAJOR_VERSION >= 8u` check already set the macro to 1 (DPC++ 2026.0 doesn't define the `SYCL_EXT_ONEAPI_GROUP_LOAD_STORE` feature-test macro the check looked at first). Setting it to 0 by hand doesn't work either: the fallback calls the `sycl::sub_group` member `load`/`store`, and icpx 2026.0 fails with `no member named 'load' in 'sycl::sub_group'`. The macro is defined in a header shipped with dpnp, hence the changelog entry. The default build compiles the same code as before. With icpx 2026.2, a syntax-only compile of both headers passes without warnings, and static asserts confirm that `needs_workaround` and `can_use_reduce_over_group` keep their values for `logical_or<bool>` and for the `int64`/`uint64` `multiplies`. 5ecc583
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
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.
DPC++ 2026.0 is the minimum compiler (the conda recipes reject anything older), and every 2026.x release ships libsycl 9 (
__LIBSYCL_MAJOR_VERSION 9). Two__LIBSYCL_MAJOR_VERSIONchecks in the libtensor headers therefore always take the same branch.This PR:
__LIBSYCL_MAJOR_VERSION < 7term fromneeds_workaroundinkernels/reductions.hpp, which keptsycl::logical_or<bool>off reduce-over-group for older compilers. The term is always false; theint64/uint64sycl::multipliesexclusion stays.USE_GROUP_LOAD_STOREfromutils/sycl_utils.hpp, sosub_group_loadandsub_group_storealways usegroup_load/group_storefromsycl_ext_oneapi_group_load_store. The__LIBSYCL_MAJOR_VERSION >= 8ucheck already set the macro to 1 (DPC++ 2026.0 doesn't define theSYCL_EXT_ONEAPI_GROUP_LOAD_STOREfeature-test macro the check looked at first). Setting it to 0 by hand doesn't work either: the fallback calls thesycl::sub_groupmemberload/store, and icpx 2026.0 fails withno member named 'load' in 'sycl::sub_group'. The macro is defined in a header shipped with dpnp, hence the changelog entry.The default build compiles the same code as before. With icpx 2026.2, a syntax-only compile of both headers passes without warnings, and static asserts confirm that
needs_workaroundandcan_use_reduce_over_groupkeep their values forlogical_or<bool>and for theint64/uint64multiplies.