[Mlir-commits] [mlir] [mlir][bufferization] Support custom types at function boundaries (PR #159766)

[Andrei Golubev]

================
@@ -43,6 +43,18 @@ def Bufferization_TensorLikeTypeInterface
       /*args=*/(ins
         "::mlir::bufferization::BufferLikeType":$bufferType,
         "::llvm::function_ref<::mlir::InFlightDiagnostic()>":$emitError)
+    >,
+    InterfaceMethod<[{
----------------
andrey-golubev wrote:

> But I think that's not possible because you wouldn't be able to configure identity/fully dynamic layout maps at the function boundary.

I'm not sure I understand this part, can you explain more? Do you mean the `void setFunctionBoundaryTypeConversion(LayoutMapOption layoutMapOption);` setter that makes the conversion `LayoutMapOption` value-dependent? I think, yes, if this is a hard blocker, an option callback must stay - passing `LayoutMapOption` via interfaces is probably a pain (if possible without hacks or a significant redesign).

> Function boundaries are always a bit special, so I think having an options callback is desirable also for custom tensor/buffer types.

Fair point. Let's go with this then. I think I could do it a bit differently: for `TensorType` (current API), we keep the logic "as is", otherwise - for `TensorLikeType` - we always call it's `getBufferType()`? This would preserve single conversion "interface" - the options callback and also give us some sane default behavior for any type (i.e. i wouldn't need to create --test-one-shot-bufferize pass yet).

> That is the case in every production compiler that I'm aware of. This is not the only flag that cannot be customized as a pass flag. AllocationFn, MemCpyFn is another one.

Right, also in our case that's the way it is (fwiw, this is probably inevitable). I was a bit lazy to have a test pass in MLIR for custom types though (i'll probably have one anyway but later: to test how builtins with `tensor encoding` -> `memref layout` behave, this is one of the important things we use everywhere in our downstream).

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