Closed mhoemmen closed 1 month ago
Suggested fix: Write a separate follow-on paper that addresses layout_left
, layout_right
, layout_left_padded
, and layout_right_padded
all at once.
For the padded layouts, if the leftmost resp. rightmost extent gets strided_slice
and its .extent
is a compile-time value, then preserve the layout (taking care to preserve the stride, which might entail making it a run-time value -- check all cases here).
Suppose that I want to vectorize a 1-D array copy operation using
mdspan
andaligned_accessor
(P2897). I have acopy_8_floats
function that expresses a hardware instruction for copying a contiguous array of 8float
s, where the start of the array is aligned to8 * sizeof(float)
(32) bytes.The natural next step would be to use
copy_8_floats
to implement copying 1-Dfloat
arrays by the usual "strip-mining" approach.One must use
strided_slice
so that the resulting extent is fully known at compile time. Usingindex-pair-like
(e.g.,tuple
) would result in a run-time extent, because both elements of the pair would have run-time components.There are two problems with the above code.
submdspan
results always havelayout_stride
..offset
only takes asize_t
offset. Thus, it discards compile-time information, like knowing that the offset is divisible by some overalignment factor.I suggest the following strategy to fix these issues.
layout_left_padded
andlayout_right_padded
.layout_left
andlayout_right
with a separate paper, because C++26 is still a working draft.Regarding fixing (2), ([mdspan.submdspan.submdspan] paragraph 6](https://eel.is/c++draft/views.multidim#mdspan.submdspan.submdspan-6) says that
submdspan(src, slices...)
has effects equivalent to the following.The problem is
AccessorPolicy::offset_policy(src.accessor())
. Theoffset_policy
is just a type, andoffset
returnsoffset_policy::data_handle_type
. If we want an offset with suitable compile-time alignment to have a different accessor type, then we would need two changes. First,offset
would need an overload taking a type that expresses the product of a compile-time integer (of suitable alignment) and a run-time integer. Second, we would need some way to get the accessor type corresponding to thatoffset
overload -- say, a new templated type alias whose template parameter is the type of the correspondingoffset
overload's parameter. Given thatoffset
is already part of the accessor, this would make more sense than introducing a customization point just for the offset accessor policy.The work-around for a known accessor type is to replace
submdspan
and handle the accessor conversion by hand. The source accessor can still have anoffset
overload that takes the offset as a type other thansize_t
.Given that this work-around is easy to do, should only be needed for very special cases, and avoids a big design change to the accessor policy requirements, it should suffice.