[PATCH v1 0/4] libstdc++: Implement first part of submdspan.

[Luc Grosheintz]

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 <luc.grosheintz@gmail.com>
> wrote:
> 
>>
>>
>> On 10/3/25 12:09 PM, Tomasz Kaminski wrote:
>>> On Thu, Oct 2, 2025 at 11:34 AM Luc Grosheintz <luc.grosheintz@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?
>>
> 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).

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
>>>>
>>>>
>>>
>>
>>
>