Implement P3663 (Future-proof submdspan_mapping) by mhoemmen · Pull Request #408 · kokkos/mdspan

mhoemmen · 2025-05-20T23:05:52Z

Implement P3663 (Future-proof submdspan_mapping).

Feature is ON by default. To disable it, set the CMake option MDSPAN_ENABLE_P3663 to OFF.

Over various commits we've simplified the implementation so that it works with C++17 and subsequent C++ versions. P3663 relies on std::constant_wrapper; we've tested with a version of GCC that implements it, so we can say with some confidence that it "forward-ports" all the way to C++26.

It currently requires the C++23 feature "deducing this" in order to compile. I've tested it with dev Clang (21.0.0). It should work fine with Clang 20.

Also implement exposition-only __mdspan_integral_constant_like concept, which is useful for canonicalization and Mandates.

sizeof...(Slices) == 0 case builds and passes tests.

Set the following CMake options. -DCMAKE_CXX_FLAGS="-std=c++2c" -DMDSPAN_CXX_STANDARD=26 You'll get a warning, but it seems to work.

* canonical-ice * subtract-ice * de-ice * check-static-bounds

submdspan_canonicalize_slices now works for one strided_slice. Fix canonical_ice (wrong order in subtraction; wording is fine).

Attempt to change over submdspan to use canonicalization without doing much else. It fails to build; a lot of layout mappings seem to get the wrong mapping result type. It builds and passes tests with P3663 support off.

submdspan builds now when submdspan_mapping is called with canonical slices, but the submdspan test fails. Investigate whether this is a bug in the implementation.

Fix extent computation for std::complex. It builds and passes tests. NEXT STEPS: * Make it ill-formed to call submdspan_mapping with non-canonical slice types * Make P3663 version only use constant_wrapper and canonical slice types in submdspan_mapping_impl functions

(submdspan_mapping_impl)

All submdspan_mapping_impl functions now check that every k-th slice type is a canonical k-th slice type. This ensures that submdspan_mapping_impl is only well-formed for canonical k-th slice types, and is ill-formed otherwise.

in P3663 branch only.

Don't need to specialize for all integral-constant-like, just for std::constant_wrapper.

tests/test_dims.cpp

mhoemmen · 2026-02-11T15:35:50Z

include/experimental/__p2630_bits/submdspan_extents.hpp

+)
+MDSPAN_INLINE_FUNCTION
+constexpr Integral first_of(const Integral &i) {
+  // FIXME (mfh 2025/06/06) This is broken, but it's better than it was.


We should just fix the non-P3663 branch if we intend to keep it.

mhoemmen · 2026-02-11T15:36:09Z

include/experimental/__p2630_bits/submdspan_extents.hpp

+  return {};
+}
+#else
+// NOTE This is technically not conforming.


We should just fix this.

include/experimental/__p2630_bits/submdspan_extents.hpp

mhoemmen · 2026-02-11T15:41:47Z

include/experimental/__p2630_bits/submdspan_extents.hpp

+// in constant expressions if they are integral-constant-like.
+
+template<size_t k, class S_k, class IndexType, size_t... Exts>
+  constexpr check_static_bounds_result check_static_bounds(


FIXME In R3, this returns bool instead of an enum.

include/experimental/__p2630_bits/submdspan_extents.hpp

mhoemmen · 2026-02-11T15:43:59Z

include/experimental/__p2630_bits/submdspan_extents.hpp

+  else if constexpr (detail::is_std_complex<Slice>) {
+#if ! defined(MDSPAN_CONSTANT_WRAPPER_WORKAROUND)
+    // GCC 11.4.0 (C++20) accepts this code, but Clang 14 does not.
+    return strided_slice{


Just delete this branch.

include/experimental/__p2630_bits/submdspan_extents.hpp

mhoemmen · 2026-02-11T15:44:37Z

include/experimental/__p2630_bits/submdspan_extents.hpp

+  const extents<IndexType, Extents...>& exts,
+  Slices... slices)
+{
+  return std::tuple{


Consider using Kokkos::tuple instead of std::tuple.

mhoemmen · 2026-02-11T15:53:34Z

include/experimental/__p2630_bits/submdspan_mapping.hpp

+  return static_cast<common_t>(first_of(slice)) ==
         static_cast<common_t>(ext);
+#else
+  // NOTE (mfh 2025/06/06) The original implementation was not conforming.


We should decide whether to fix the non-P3663 case or just remove it and make P3663 the only implementation.

mhoemmen · 2026-02-11T15:55:57Z

tests/test_strided_slice.cpp

+template<class OffsetType, class ExtentType, class StrideType>
+void test_strided_slice(OffsetType offset, ExtentType extent, StrideType stride)
+{
+  // Some compilers are bad at CTAD for aggregates.


We should consider branching based on compilers where it's known to work. It would be good to test that CTAD works.

mhoemmen · 2026-02-12T18:29:08Z

PR #447 will remove import of dims into the experimental namespace. This PR should be changed not to do that. (There's no promise of backwards compatibility for the experimental namespace.)

nmm0

Ok some initial comments, I got through a good chunk of it but not everything.

nmm0 · 2026-02-12T18:05:27Z

benchmarks/submdspan/CMakeLists.txt

+#if(MDSPAN_ENABLE_CUDA)
+#  add_subdirectory(cuda)
+#endif()


Suggested change

#if(MDSPAN_ENABLE_CUDA)

# add_subdirectory(cuda)

#endif()

nmm0 · 2026-02-12T18:12:35Z

include/experimental/__p2630_bits/constant_wrapper.hpp

@@ -0,0 +1,265 @@
+#pragma once


I think we should pull this into a separate PR.

Also since we are pulling this in should we ask Zach if it's under a license or public domain? I couldn't find any info in the source code so I suspect it is the latter.

@nmm0 I'm inclined to check whether any (VERY VERY NEW) compiler comes with a constant_wrapper implementation. If it does, we can test the code with the actual std::constant_wrapper, remove the back-port, and leave only the pre-C++26 work-around (that looks like integral_constant). What do you think?

Compiler Explorer's GCC trunk has std::constant_wrapper: https://godbolt.org/z/3e4qvEvv1 . That means we have a way to test this with the actual std::constant_wrapper. That motivates removing the back-port, as long as we know that it actually works with std::constant_wrapper.

C++26 may still see changes to std::constant_wrapper -- there's a fix paper in flight -- but I don't think it would apply to anything in this PR. (The paper would change behavior for callables.)

It does look like GCC16 will have std::constant_wrapper (so i guess it made the cut): https://gcc.gnu.org/gcc-16/changes.html

I'm fine with having a constant wrapper backport though, just will be easier to review in another PR

@nmm0 The back-port is really only useful for Clang 21 and just barely for GCC 15. Anything earlier won't have a chance of building a constant_wrapper that looks enough like constant_wrapper to call it a back-port.

I've removed the back-port. GCC trunk builds it correctly. I'm not convinced that MDSPAN_ENABLE_P3663 is always defined in the build, though.

nmm0 · 2026-02-12T18:37:20Z

include/experimental/__p2630_bits/remove_cvref.hpp

+
+#include <type_traits>
+
+namespace MDSPAN_IMPL_STANDARD_NAMESPACE {


I think this is fine here but at some point if we reorganize files I think we could move all of these little backports of C++ things that we need into its own utility folder.

That's a good idea! If we end up removing the constant_wrapper back-port (please see my comment above), then there won't be quite so many long files here.

include/experimental/__p2630_bits/strided_slice.hpp

include/experimental/__p2630_bits/submdspan.hpp

include/experimental/__p2630_bits/submdspan_extents.hpp

nmm0 · 2026-02-12T18:57:41Z

CMakeLists.txt


 option(MDSPAN_ENABLE_CONCEPTS "Try to enable concepts support by giving extra flags." On)

+option(MDSPAN_ENABLE_P3663 "Enable implementation of P3663 (Future-proof submdspan_mapping)." On)


I think this is actually our only cmake-based feature switch? So this actually leads to the question of how we do this, because right now if someone is using mdspan via cmake this does nothing (as it only enables a compile definition for benchmarks).

So I suppose the question is do we want to add them to a target (e.g. via target_compile_definitions) or via a #cmakedefine sort of thing like Kokkos does where we generate a header with the define. We could even let it be overrideable via a define.

I actually am leaning towards the latter because we could use it in our single-header mode and the value could be overriden if using the header only mode via a define.

@nmm0 wrote:

... because right now if someone is using mdspan via cmake this does nothing....

Practically, it changes the implementation by changing the macro definitions in the headers -- at least it should! I might be missing something here.

Should we consider just removing this option and making the library implement P3663 unconditionally?

mhoemmen · 2026-02-15T23:26:07Z

Compiler Explorer's version of GCC trunk has std::constant_wrapper: https://godbolt.org/z/3e4qvEvv1 .

For both P3663 and no-P3663 branches, fix __mdspan_is_index_like_v so that it now correctly excludes std::bool_constant or any integral-constant-like with bool value type.

to use a lambda with `auto&&... canonical_slices` capture instead of a named functor.

GCC trunk ("16.0.1") has std::constant_wrapper. This commit fixes any build errors that resulted from using that as the "constant_wrapper" in mdspan. It also works around some pack indexing issues that seem unique to GCC.

mhoemmen · 2026-02-16T16:00:44Z

Hi @nmm0 ! GCC trunk ("16.0.1") has std::constant_wrapper. Commit 971c8fb builds and passes tests with that, using the following cmake options.

cmake ${SOURCE_DIRECTORY} \
  -DMDSPAN_ENABLE_TESTS=ON \
  -DMDSPAN_ENABLE_EXAMPLES=ON \
  -DMDSPAN_ENABLE_P3663=ON \
  -DCMAKE_CXX_FLAGS="-Wall -std=c++26" \
  -DCMAKE_CXX_COMPILER=${GCC_TRUNK_PREFIX}/bin/g++ \
  -DMDSPAN_CXX_STANDARD=26

As a result, I think it's safe to remove the constant_wrapper back-port entirely.

GCC trunk ("16.0.1") has std::constant_wrapper. This commit builds and passes tests with that. Thus, I've removed the constant_wrapper back-port (that really only worked with GCC 15 and Clang 21). There are now only two branches. 1. Use actual std::constant_wrapper and std::cw 2. Use something that only superficially has the same interface but is really just an integral_constant clone

mhoemmen added 5 commits May 6, 2025 14:23

P3663: Add constant_wrapper implementation

ef2152e

It currently requires the C++23 feature "deducing this" in order to compile. I've tested it with dev Clang (21.0.0). It should work fine with Clang 20.

P3663: Test that strided_slice works with std::cw

00bf62f

Also implement exposition-only __mdspan_integral_constant_like concept, which is useful for canonicalization and Mandates.

P3663: Stub submdspan_canonicalize_slices

62d8bba

sizeof...(Slices) == 0 case builds and passes tests.

Support Clang 21.0.0 -std=c++2c

d8332ac

Set the following CMake options. -DCMAKE_CXX_FLAGS="-std=c++2c" -DMDSPAN_CXX_STANDARD=26 You'll get a warning, but it seems to work.

Implement check-static-bounds and others

c847a54

* canonical-ice * subtract-ice * de-ice * check-static-bounds

mhoemmen force-pushed the P3663 branch from 02b6429 to c847a54 Compare May 20, 2025 23:14

mhoemmen added 2 commits May 21, 2025 16:09

Fix submdspan_canonicalize_slices for one slice

0259594

Fix canonical_ice & 1 strided_slice

7092b24

submdspan_canonicalize_slices now works for one strided_slice. Fix canonical_ice (wrong order in subtraction; wording is fine).

mhoemmen force-pushed the P3663 branch from a609ed2 to 7092b24 Compare May 21, 2025 22:45

mhoemmen added 8 commits May 21, 2025 16:49

Put dims in the correct namespace

825e659

Add submdspan_canonicalize_slices rank 2 test

cc8b3ef

CHECKPOINT

71b85ba

Attempt to change over submdspan to use canonicalization without doing much else. It fails to build; a lot of layout mappings seem to get the wrong mapping result type. It builds and passes tests with P3663 support off.

IT BUILDS -- pulled in R0 impl

b049333

submdspan_mapping with canonical slices actually builds now

de58bc0

CHECKPOINT

a336fb0

submdspan builds now when submdspan_mapping is called with canonical slices, but the submdspan test fails. Investigate whether this is a bug in the implementation.

Deploy is_canonical_slice_type in layout_left

c82425f

(submdspan_mapping_impl)

mhoemmen force-pushed the P3663 branch from 02d3694 to c82425f Compare May 23, 2025 17:24

mhoemmen added 10 commits May 23, 2025 11:29

Add is_canonical_slice_type check to all submdspan_mapping_impl

a87b24d

Check canonical k-th slice type

25f725e

All submdspan_mapping_impl functions now check that every k-th slice type is a canonical k-th slice type. This ensures that submdspan_mapping_impl is only well-formed for canonical k-th slice types, and is ill-formed otherwise.

Replace integral_constant with cw

0e17f67

in P3663 branch only.

Remove unneeded first_of and last_of overloads

7ba02e6

Remove index_pair_like definition

8a5c18f

Replace is_range_slice with is_range_slice_v

3a5bcc7

Simplify StaticExtentFromStridedRange

c9aa31d

Don't need to specialize for all integral-constant-like, just for std::constant_wrapper.

Simplify extents_constructor for P3663

cc99e2c

Remove superfluous TODO

443d3fc

Reconcile implementation with draft P3663R2

57ae578

mhoemmen changed the title ~~Implement P3663R1 (Future-proof submdspan_mapping)~~ Implement P3663R2 (Future-proof submdspan_mapping) May 27, 2025

mhoemmen changed the title ~~Implement P3663R2 (Future-proof submdspan_mapping)~~ Implement D3663R2 (Future-proof submdspan_mapping) May 27, 2025

mhoemmen commented Feb 11, 2026

View reviewed changes

tests/test_dims.cpp Show resolved Hide resolved

mhoemmen commented Feb 11, 2026

View reviewed changes

include/experimental/__p2630_bits/submdspan_extents.hpp Outdated Show resolved Hide resolved

mhoemmen commented Feb 11, 2026

View reviewed changes

include/experimental/__p2630_bits/submdspan_extents.hpp Show resolved Hide resolved

mhoemmen commented Feb 11, 2026

View reviewed changes

include/experimental/__p2630_bits/submdspan_extents.hpp Show resolved Hide resolved

mhoemmen commented Feb 11, 2026

View reviewed changes

include/experimental/__p2630_bits/submdspan_extents.hpp Outdated Show resolved Hide resolved

mhoemmen commented Feb 11, 2026

View reviewed changes

include/experimental/__p2630_bits/submdspan_extents.hpp Outdated Show resolved Hide resolved

mhoemmen commented Feb 11, 2026

View reviewed changes

include/experimental/__p2630_bits/submdspan_extents.hpp Outdated Show resolved Hide resolved

mhoemmen commented Feb 11, 2026

View reviewed changes

mhoemmen mentioned this pull request Feb 11, 2026

move padded layouts and dims from Experimental to the standard namespace #447

Merged

nmm0 reviewed Feb 12, 2026

View reviewed changes

Remove strided_slice deduction guide

6fe00d7

mhoemmen added 9 commits February 15, 2026 16:40

Merge branch 'stable' into P3663

524bdaf

Fix dims merge

2bbe748

Fix __mdspan_is_index_like_v

345dda4

For both P3663 and no-P3663 branches, fix __mdspan_is_index_like_v so that it now correctly excludes std::bool_constant or any integral-constant-like with bool value type.

Remove C++26 branch from submdspan

e0678c9

Simplify submdspan per review comment

f3da596

to use a lambda with `auto&&... canonical_slices` capture instead of a named functor.

Simplify first_of definition

087936f

Simplify first_of more

efb4827

Remove outdated comment

e1505dd

Fixes so that GCC trunk builds

971c8fb

GCC trunk ("16.0.1") has std::constant_wrapper. This commit fixes any build errors that resulted from using that as the "constant_wrapper" in mdspan. It also works around some pack indexing issues that seem unique to GCC.


		#include <type_traits>

		namespace MDSPAN_IMPL_STANDARD_NAMESPACE {


		option(MDSPAN_ENABLE_CONCEPTS "Try to enable concepts support by giving extra flags." On)

		option(MDSPAN_ENABLE_P3663 "Enable implementation of P3663 (Future-proof submdspan_mapping)." On)

Conversation

mhoemmen commented May 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mhoemmen commented Feb 12, 2026

Uh oh!

nmm0 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mhoemmen commented Feb 15, 2026

Uh oh!

mhoemmen commented Feb 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

mhoemmen commented May 20, 2025 •

edited

Loading

mhoemmen commented Feb 16, 2026 •

edited

Loading