On 10/3/25 12:09 PM, Tomasz Kaminski wrote:
On Thu, Oct 2, 2025 at 11:34 AM Luc Grosheintz <luc.groshei...@gmail.com>
wrote:
This patch series contains everything up to submdspan_extents and
implements them as described in N5014, i.e. without P3663.
The reasons to not include P3663 are:
- Doing both allows us to benchmark the change.
My concern is that this duplicates the amount of reviews required,
and work spent on this paper.
That's a very valid argument. I'll locally incorporate all
you feedback for v1. We could pause and continue directly
with P3663, is that better for you?
There's a few things I'd like to do:
1. I'm very curious to see if this canonicalization has
an impact on the generated code.
2. I should also re-check the mapping::operator() for all
five layouts; and I'd like to analyze some slightly more
advanced usecases and compare to naive almost C-style code.
- Carefully implementing both, automatically leads to looking at the
problem from different angles. We can spot differences between the
two proposals. One such difference is that P3663 seems to allow
ambiguous slices, e.g. slices that convert to both full_extent and
index_type.
Yes, this was an intentional change in the paper.
That's interesting, what was the reason?
- P3663 hasn't been finalized yet, if we implement it now we'll need
to keep track of the difference. That's easier (or at least not
harder) if we have a commit containing the already applied changes
from N5014.
We hope that it will be finalized in today's telecon.
Congrats & best of luck!
- With a casting layer in place, the changes in the paper are quite
contained, e.g. remove cases for handling tuple, slightly refine
the range checks of slices (more can be done at compile-time).
The wording before P3663 does not allow slices to be canonicalized
before calling submdspan_mapping customization point, at least for user
defined-layouts. This is not an issue for the sub extents, as it is not
customizable.
But it will show up in the next commits. Maybe it is less of the issues as
__subextents
will already perform most of the required checks.
- We could easily revert P3663 if needed.
Luc Grosheintz (4):
libstdc++: Implement strided_slice from <mdspan>. [PR110352]
libstdc++: Implement full_extent_t. [PR110352]
libstdc++: Implement submdspan_mapping_result. [PR110352]
libstdc++: Implement submdspan_extents. [PR110352]
libstdc++-v3/include/bits/version.def | 9 +
libstdc++-v3/include/bits/version.h | 9 +
libstdc++-v3/include/std/mdspan | 311 ++++++++++++++++++
libstdc++-v3/src/c++23/std.cc.in | 7 +-
.../testsuite/23_containers/mdspan/int_like.h | 9 +
.../mdspan/submdspan/strided_slice.cc | 46 +++
.../mdspan/submdspan/strided_slice_neg.cc | 19 ++
.../mdspan/submdspan/submdspan_extents.cc | 159 +++++++++
.../mdspan/submdspan/submdspan_extents_neg.cc | 66 ++++
9 files changed, 633 insertions(+), 2 deletions(-)
create mode 100644
libstdc++-v3/testsuite/23_containers/mdspan/submdspan/strided_slice.cc
create mode 100644
libstdc++-v3/testsuite/23_containers/mdspan/submdspan/strided_slice_neg.cc
create mode 100644
libstdc++-v3/testsuite/23_containers/mdspan/submdspan/submdspan_extents.cc
create mode 100644
libstdc++-v3/testsuite/23_containers/mdspan/submdspan/submdspan_extents_neg.cc
--
2.50.1
