mdspan converting constructors

[nmm0]

Closes #6805

This PR adds constructors for Kokkos::View that convert from std::mdspan.

• If the VIew is compile-time unmanaged, the conversion is implicit (only matters in C++20)
• Constraints: the layout is mappable to mdspan layout mappings
  • Kokkos::LayoutLeft -> std::layout_left_padded<N>::mapping
  • Kokkos::LayoutRight -> std::layout_right_padded<N>::mapping
  • Kokkos::LayoutStride -> std::layout_stride

It also adds to_mdspan and operator mdspan that converts to the "natural" mdspan type, that is the type that closely represents the internal view state.

Requirements for this PR (currently based on top of these changes):

• Pull in the more recent mdspan (Done in Update mdspan tpl to latest stable #6862)
• Move some utility classes from Kokkos_ViewMapping to a new header Kokkos_ViewDataAnalysis. Once BasicVIew is implemented, this could all be removed (Done in Split some classes from Kokkos_ViewMapping #6859)

[crtrott]

Besides separating PRs for moving stuff and adding the new functionality: can't we have this all simpler?
Is there something wrong with defining the "natural mdspan type" for a View, and then having a constructor which takes exactly that View, after which we can rely largely on the convertability of the incoming mdspan to the natural mdspan?

This code snippet here defines natural mdspan

template<class L>
struct LayoutMap;

template<>
struct LayoutMap<Kokkos::LayoutRight> { using type = Kokkos::layout_right; };
template<>
struct LayoutMap<Kokkos::LayoutLeft> { using type = Kokkos::layout_left; };
template<>
struct LayoutMap<Kokkos::LayoutStride> { using type = Kokkos::layout_stride; };

template<class ViewType>
void foo() {
  using element_type = typename ViewType::value_type;
  using index_type = typename ViewType::execution_space::size_type;
  using extents_type = typename Kokkos::Experimental::Impl::ExtentsFromDataType<index_type, typename ViewType::data_type>::type;
  using layout_type = typename LayoutMap<typename ViewType::array_layout>::type;
  using mdspan_type = Kokkos::mdspan<element_type, extents_type, layout_type>;
  printf("%s\n", typeid(ViewType).name());
  printf("%s\n", typeid(mdspan_type).name());
}

And then the constructor we would need is simply:

MDSPAN_CONDITIONAL_EXPLICIT(traits::is_managed)
View(mdspan_type mds):View(mds.data_handle(), kokkos_layout_from_mapping(mds.mapping()) ) {}

Do you see anything wrong with this approach? The mdspan convertability and constructibility should enforce all the desired "this constructor works" properties wouldn't it?

[nmm0]

Besides separating PRs for moving stuff and adding the new functionality: can't we have this all simpler? Is there something wrong with defining the "natural mdspan type" for a View, and then having a constructor which takes exactly that View, after which we can rely largely on the convertability of the incoming mdspan to the natural mdspan?

This code snippet here defines natural mdspan

template<class L>
struct LayoutMap;

template<>
struct LayoutMap<Kokkos::LayoutRight> { using type = Kokkos::layout_right; };
template<>
struct LayoutMap<Kokkos::LayoutLeft> { using type = Kokkos::layout_left; };
template<>
struct LayoutMap<Kokkos::LayoutStride> { using type = Kokkos::layout_stride; };

template<class ViewType>
void foo() {
  using element_type = typename ViewType::value_type;
  using index_type = typename ViewType::execution_space::size_type;
  using extents_type = typename Kokkos::Experimental::Impl::ExtentsFromDataType<index_type, typename ViewType::data_type>::type;
  using layout_type = typename LayoutMap<typename ViewType::array_layout>::type;
  using mdspan_type = Kokkos::mdspan<element_type, extents_type, layout_type>;
  printf("%s\n", typeid(ViewType).name());
  printf("%s\n", typeid(mdspan_type).name());
}

And then the constructor we would need is simply:

MDSPAN_CONDITIONAL_EXPLICIT(traits::is_managed)
View(mdspan_type mds):View(mds.data_handle(), kokkos_layout_from_mapping(mds.mapping()) ) {}

Do you see anything wrong with this approach? The mdspan convertability and constructibility should enforce all the desired "this constructor works" properties wouldn't it?

@crtrott Yeah I think the simpler approach is better, I was trying to make the API like mdarray but thinking about it a bit more I realized that's not what we want. Actually the approach I have right now doesn't have the right constraints anyway.

[nmm0]

Also it still needs to be constrained on is_managed but it doesn't need to be conditionally explicit

[crtrott]

I think conditional explicit is fine. We allow construction from pointer of a "managed" view.

[dalg24]

Why do we want 0s for static extents?

[nmm0]

I believe that's what currently the ViewOffset does, so this would have a similar behavior

[dalg24]

Please expand the description. Referring to an issue that in turn point to an ISO C++ paper makes it difficult to audit.

[dalg24]

A few extra minor comments on the tests

[dalg24]

Tests were in alphabetic order and there is a MDSpan test.
I suppose you meant to define it in the same exe as the other view tests but I tend to think you should define it L187 in sources 1B.

Other than that looks good

[dalg24]

Retest this please

[dalg24]

Failure in the CUDA-11.6-NVCC-DEBUG build on Jenkins

4: [ RUN      ] cuda.view_mdspan_conversion
4: The specified run-time extent for Kokkos::View 'UNMANAGED' does not match the compile-time extent in dimension 0. The given extent is 0 but should be 7.
4: 
4: Backtrace:
4: [0x55555661903f] 
4: [0x5555565f8962] 
4: [0x5555555997ab] 
4: [0x555556116fd1] 
4: [0x55555610ebd8] 
4: [0x55555610af67] 
4: [0x5555560ef6ed] 
4: [0x5555560de0de] 
4: [0x5555560a1118] 
4: [0x555556099dfd] 
4: [0x5555560987af] 

[crtrott]

Retest this please!