[Mlir-commits] [mlir] [mlir][bufferization] Introduce createMemRefLayoutFn hook (PR #195622)

[Matthias Springer]

================
@@ -246,6 +246,13 @@ AllocTensorOp::getBufferType(Value value, const BufferizationOptions &options,
     return getOperation()->emitError("could not infer memory space");
   }
 
+  if (options.createMemRefLayoutFn) {
+    if (auto layout = options.createMemRefLayoutFn(getType())) {
----------------
matthias-springer wrote:

> > Just an idea: we already have a memory_space attribute on alloc_tensor. Should the layout map also be an attribute? Or maybe the entire buffer type should be passed as a TypeAttr?
> 
> On this, i don't know. Right now, even memory space is technically something that exists solely on builtin memrefs (buffer-like-type doesn't expose any memory space APIs -- I think it was initially rejected some long time ago when I introduced buffer-like-type). The layout map itself technically only exists in memref world. So alloc_tensor can at best have a tensor _encoding_ (which is, i guess, the "counterpart" of the layout) i.e. to not leak lower-level details? To be honest, I am not sure why we have 2 distinct entities to represent kind of "similar" concepts: "user payload inside of builtin type".

I didn't have time to digest your full reply yet. Just a quick comment that came to mind: `alloc_tensor` sits at the boundary between tensor and buffer land. E.g., the documentation talks about buffer allocations. I agree that the tensor type itself should not have a memory space / layout map, but IMO an attribute on the `alloc_tensor` op to indicate the future buffer type would be reasonable.

It could be the final buffer type. Not a memory space or layout map. But instead the full `memref` type or whatever buffer type you are using. (A type attribute with the constraint that the type must implement `BufferLikeTypeInterface`.)


https://github.com/llvm/llvm-project/pull/195622