# Extracting dynamic offsets/strides from memref

**URL:** <https://discourse.llvm.org/t/extracting-dynamic-offsets-strides-from-memref/64170>\
**Category:** MLIR\
**Created:** [July 29, 2022, 10:49pm UTC](https://discourse.llvm.org/t/extracting-dynamic-offsets-strides-from-memref/64170 "2022-07-29T22:49:30Z")\
**Posts on this page:** 1\
**Showing post:** 16

<div class="post-metadata">

**Author:** ![ftynse](https://sea1.discourse-cdn.com/flex021/user_avatar/discourse.llvm.org/ftynse/32/18644_2.png) [@ftynse](https://discourse.llvm.org/u/ftynse)\
**Post date:** [August 11, 2022, 9:29am UTC](https://discourse.llvm.org/t/extracting-dynamic-offsets-strides-from-memref/64170/16 "2022-08-11T09:29:40Z")

</div>

> [@nicolasvasilache](#):
>
> @ftynse in case he has a different reading / sensibility than me on this topic.

I don’t really have an opinion here, that’s why I haven’t commented so far.

> [@nicolasvasilache](#):
>
> There is one aspect that happens at the LLVM level today that I do not see a clear path on: inserting and extracting in and out of the `llvm.struct` that represents the descriptor provides a structuring type that does not exist outside of the LLVM dialect.

The major reason for using `struct` was the impossibility of performing one-to-many type conversions. The common wisdom was that something will do SRoA and DCE at a lower level (LLVM dialect or LLVM IR) anyway, so this is not a performance issue.

> [@nicolasvasilache](#):
>
> - adding a hypothetical `memref_descriptor` type specifically for this purpose.

AFAIK, descriptor is a concept specific to the Memref-\>LLVM lowering. Since you mentioned the importance of non-LLVM outfeeds, you probably don’t want to lift this concept to `memref` itself.

Do we practically need access to the base pointer? If not, I would consider adding `!shape.strided` type into the shape dialect to represent the (sizes + strides + offset) information, which is a more of a memref-level concept.

In any case, I would suggest phrasing this in terms of “strides/offsets” or “strided format” to avoid lifting the implementation detail into the memref dialect/type definition.

> [@nicolasvasilache](#):
>
> adding hypothetical `struct` type that at a higher level of abstraction than LLVM with its own `insert` / `extract`.

We already have the bulit-in tuple type, just no operations to insert/extract. Struct may come with data layout considerations that nobody wants to handle as this level.

> [@nicolasvasilache](#):
>
> One potential drawback would be that it is overkill to extract all `%base, %offset, %sizes:2, %strides:2` if we only need to manipulate say `%strides#0` but I don’t think this is really a concern in practice for now.

This shouldn’t be a runtime performance problem as long as there is DCE at some later stage when the memref is transformed into a descriptor, or some clever lowering/canonicalization that avoids emitting spurious `extractvalue` equivalents. There is a some compile-time cost though.

> [@nicolasvasilache](#):
>
> The size is definitely used in a bunch of other places in codegen and memref.dim continues to make sense but we still want to discourage accessing and manipulating individual strides / offsets outside of structured `memref.reshape`, `memref.subview` ops and friends.

I think the rationale for that was to support aliasing analysis. With all sorts of casts that I lost track of, we are likely past the point where we could still have a happy path by construction, so this may be less of a concern.

> [@nicolasvasilache](#):
>
> To that effect, having a single op to get the descriptor seems more appealing.  
> It would also be clear that wherever we see a non-strided memref, the descriptor does not exist and verification errors ensue.

I don’t see a difference between “error: memref.get\_strided\_shape at file.mlir:123:45: op requires operand #0 to satisfy strided memref” and “error: memref.get\_stride at file:123:45: op requires operand #0 to satisfy strided memref”, which is the error message we would get by having the `AnyStridedMemRef` type constraint in the op definition. There are multiple other such ops in the dialect.

---

_[View the full topic](https://discourse.llvm.org/t/extracting-dynamic-offsets-strides-from-memref/64170)._