<div dir="ltr"><div dir="ltr">Hi Prashanth,<div><br></div><div>Do you know how that would map to the mdspan proposal of C++? (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0009r9.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0009r9.html</a>)</div><div>Should we split the stride from the bound, to represent sub-rectangles, or padding? (this would require 2 "size" per dimension, but it is quite common in video/image processing)<br></div><div>Should we require the stride to be multiple of one an other and in the decreasing order? (this could allow to encode transpose without having to move data around)</div><div><br></div><div>As for us, we went for an "underlying geometry" attribute/metadata, which takes a bunch of sizes.</div><div>It gives for each argument a hint on how to de-linearize the accesses (aka. the dimension's sizes), and the address computation still uses gep.</div><div>But we still need a few assert that bound the indexes to not overflow their respective dimension's upper bound, to avoid the gep delinearization to involve modulo.</div><div><br></div><div>It's far from ideal, but it allows us to support legacy codes that were written in linearized form.</div><div>Our main issue is actually handling memcpy-like code, which have both a linearized address computation but also a linearized loop nest structure...</div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><b>Alexandre Isoard</b><br></div></div></div>