Skip to content

Drop __LIBSYCL_MAJOR_VERSION checks dead with the 2026.0 minimum compiler - #3174

Merged
antonwolfy merged 3 commits into
masterfrom
drop-dead-libsycl-version-checks
Nov 8, 2026
Merged

antonwolfy merged 3 commits into
masterfrom
drop-dead-libsycl-version-checks

Conversation

@antonwolfy

@antonwolfy antonwolfy commented Nov 8, 2026 •

Copy link
Copy Markdown
Contributor

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.

  • Have you provided a meaningful PR description?
  • Have you added a test, reproducer or referred to an issue with a reproducer?
  • Have you tested your changes locally for CPU and GPU devices?
  • Have you made sure that new changes do not introduce compiler warnings?
  • Have you checked performance impact of proposed changes?
  • Have you added documentation for your changes, if necessary?
  • Have you added your changes to the changelog?

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.
@github-actions

github-actions Bot commented Nov 8, 2026 •

Copy link
Copy Markdown
Contributor

Array API standard conformance tests for dpnp=0.22.0dev1=np2py314h8d9cdd5_8 ran successfully.
Passed: 1491
Failed: 0
Skipped: 6

@github-actions

github-actions Bot commented Nov 8, 2026 •

Copy link
Copy Markdown
Contributor

View rendered docs @ https://intelpython.github.io/dpnp/index.html

@ndgrigorian ndgrigorian left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tests pass, LGTM

@antonwolfy antonwolfy self-assigned this Nov 8, 2026
@antonwolfy antonwolfy added this to the 0.22.0 release milestone Nov 8, 2026
@coveralls

coveralls commented Nov 8, 2026 •

Copy link
Copy Markdown
Collaborator

Coverage Status

coverage: 84.404% (+0.007%) from 84.397% — drop-dead-libsycl-version-checks into master

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟢 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_STORE macro.
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

@antonwolfy
antonwolfy merged commit 5ecc583 into master Nov 8, 2026
53 of 60 checks passed
@antonwolfy
antonwolfy deleted the drop-dead-libsycl-version-checks branch November 8, 2026 22:14
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
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