[Mlir-commits] [mlir] [mlir][bufferization] Support custom types (1/N) (PR #142986)

Andrei Golubev llvmlistbot at llvm.org
Mon Jun 16 01:31:03 PDT 2025


================
@@ -0,0 +1,72 @@
+//===- BufferizationConversionInterface.h - Dialect Interface ---*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+#ifndef MLIR_DIALECT_BUFFERIZATION_IR_BUFFERIZATIONCONVERSIONINTERFACE_H_
+#define MLIR_DIALECT_BUFFERIZATION_IR_BUFFERIZATIONCONVERSIONINTERFACE_H_
+
+#include "mlir/Dialect/Bufferization/IR/BufferizableOpInterface.h"
+#include "mlir/Dialect/Bufferization/IR/BufferizationTypeInterfaces.h"
+#include "mlir/IR/DialectInterface.h"
+
+namespace mlir {
+namespace bufferization {
+
+/// This class defines a virtual interface for conversions between tensor-like
+/// and buffer-like types.
+struct ConversionDialectInterface
----------------
andrey-golubev wrote:

> A dialect interface would allow you to define different type conversions for each dialect. When is that useful? 

honestly, i think you're correct.

Generally, given options, may be there's a nice way to combine the type interfaces with them. I think the immediate problem I see is the need to perform memref -> tensor mapping and that is a bit tricky since we need to pass the full type (e.g. I'd like to be able to do MemrefLayout -> Tensor Encoding but our encoding for instance also stores memory space information, so one has to provide full type). All in all, options would then be rather broad (unlike now). But perhaps this is something we can solve separately.

> You could now end up with different type conversion rules for the same type within the same program.

I think I understand. I'm somewhat concerned we have this already via BufferizableOpInterface and one extra interface for the "general case" (added here).

One of the additional reasons so far at least is that `getBufferType` works with MLIR values, not with types. Let me see if I would be able to make the type interfaces "nice". I guess ideally TensorLike <-> BufferLike is a type-level conversion, not value-level conversion.

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


More information about the Mlir-commits mailing list