[PATCH] D74820: [MLIR] Support memrefs with memref element types.

[Alex Zinenko via Phabricator via llvm-commits]

ftynse requested changes to this revision.
ftynse added a comment.
This revision now requires changes to proceed.

This is largely insufficient. What is the dynamic representation of such memrefs? How do we lower loads/stores? Do we add type some amount of type erasure (e.g. should it matter that the element type is `memref<10xf32>` or `memref<?xf32>` ?)

Don't get me wrong, I think it is important to properly nested pointers for, e.g., sparse storage. They key thing is "properly" though. We need to make sure we are working towards that instead of just relaxing the type constraints on standard types without considering the implications.

> Perhaps memref should be agnostic to the element type it contains? Tensors and Vector types can remain more constrained, but memref should be able to act on many kinds of types, not just the basic fundamental ones.

Memref points to a buffer in memory. It does not make sense to have memrefs of a type that don't have a well-defined in-memory representation.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74820/new/

https://reviews.llvm.org/D74820