On Wed, Oct 8, 2025 at 5:49 PM Luc Grosheintz <[email protected]> wrote:
> > > On 10/8/25 12:46, Tomasz Kaminski wrote: > > I have just landed the first 3 patches. > > Thanks, and sorry about not seeing too many cases of line break > after the return type. > > > > > On Fri, Oct 3, 2025 at 2:44 PM Luc Grosheintz <[email protected]> > > wrote: > > > >> > >> > >> On 10/3/25 12:09 PM, Tomasz Kaminski wrote: > >>> On Thu, Oct 2, 2025 at 11:34 AM Luc Grosheintz < > [email protected] > >>> > >>> 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? > >> > > It would be good to have P3663 implementation experience, before > > November Kona meeting. > > Good to know! > > > > >> > >> 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. > >> > > This result seem valuable, so maybe a good option would be to > > get submdspan and submdspan_mapping implemented for layout_left, > > in N5014, and then follow up with P3663 for the same layout. The P3663 > > needs to be approved before we merge. > > Okay, let's do this. I'd suggest to not be very precise about > checking of preconditions for N5014 (it feels like they're a > little off, and precise testing is what takes most of the time). > Yes, that make sense and they should be much easier to write after canonicalization. > > Then when we know we want to merge something, we can cleanup > the preconditions. > > > >> > >> 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. > >> > > Yes, I would be interested in seeing that afterwards, especially as this > is > > related > > to the simplification of pad version of linear index left/right. > > > >> > >>> > >>>> > >>>> - 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 > >>>> > >>>> > >>> > >> > >> > > > >
