[mlir] Add a new builtin `unrealized_conversion_cast` operation

[rriddle]

Summary

An unrealized_conversion_cast operation represents an unrealized conversion
from one set of types to another, that is used to enable the inter-mixing of
different type systems. This operation should not be attributed any special
representational or execution semantics, and is generally only intended to be
used to satisfy the temporary intermixing of type systems during the conversion
of one type system to another.

This operation was discussed in the following RFC(and ODM):

https://llvm.discourse.group/t/open-meeting-1-14-dialect-conversion-and-type-conversion-the-question-of-cast-operations/

Depends On D94831

[rriddle]

Rebase

[lattner]

Looking forward to this!!

mlir/include/mlir/IR/BuiltinOps.td

229

bikesheding the name, "partial_conversion_cast" has two things going on that are confusing dialect "conversion" and value "cast"ing.

WDYT about just "partial_convert" or "conversion_cast" or something like that?

231

Should this also be marked as having no side effects?

248

What is the semantic of a zero operand cast, is this a constant of some sort? Is this an undef/poison like thing?

I'm not sure what the use-case is here, but if there is one then it should be defined a bit more I think.

254

I know these are just examples, but I'd use something a bit more obviously different so it is clear it is a dialect lowering thing, e.g.:

%results:2 = partial_conversion_cast(%operand : !ast.enum) to !midlevel.selector, !midlevel.payload

mlir/lib/IR/BuiltinDialect.cpp

249

Stylistic thing, but you could define the class inside the getCanonicalizationPatterns function to scope it better.

256

Marking as no side effect would eliminate the need for this.

273

Have you considered inlining this into its own caller? I don't see a reason for the extra overhead.

[silvas]

mlir/include/mlir/IR/BuiltinOps.td

251

This is pretty non-standard syntax. Why not

partial_conversion_cast : () -> f64
partial_conversion_cast %operand : i32 -> f64
partial_conversion_cast %operand : i32 -> (i32, i32)
partial_conversion_cast %operand, %operand : (i32, i32) -> i32

My fingers and eye-parsers have that syntax memorized from countless other ops, and the current syntax is no more succinct.

mlir/lib/IR/BuiltinDialect.cpp

247

nit: space before (

[jpienaar]

mlir/include/mlir/IR/BuiltinOps.td

229

transient_cast ?

232

"An operation" doesn't add much

232

What does opaquely refer to here? E.g., how is it more opaque than a regular cast?

251

+1

[silvas]

mlir/include/mlir/IR/BuiltinOps.td

229

I think that jdd's unrealized_type_conversion is also a strong contender. I think that captures the intent really well: "there is further type conversion that needs to happen somewhere, but hasn't happened yet".

Or to use Mehdi's terminology, this op is a "promise" that further type conversions are coming later in the pipeline that will make it unnecessary.

[rriddle]

Address most comments

mlir/include/mlir/IR/BuiltinOps.td

229

Went with UnrealizedConversionCast, given that I think it bridges both worlds. (Glad I didn't have to think of a name myself.)

231

The mindset I have is that we should ideally treat this operation as conservatively as possible. Marking this as no side effecting could be lossy depending on what the conversion at the end is intended to be, given that if an operation is non side effecting it can be CSEd/moved as part of code motion/have things trivially moved around it/etc. My view of this op is that things should basically treat it as an unregistered operation/unknown call, and not make assumptions about it.

248

The use case I had in mind is that during conversion you can end up with a 1->0 conversions (most often during function signature conversion); i.e. where a type gets dropped. If uses of the original value still linger around, we have to insert a cast operation of some kind to temporarily materialize a value of the desired type. This fits in the partial lowering use cases, e.g. where you may want to lower function signatures in a ModulePass and then function bodies in a followup FunctionPass.

251

This is the standard syntax for cast operations upstream (for a few years now). I'd rather be consistent (and I also have a slight preference for this style ;)

mlir/lib/IR/BuiltinDialect.cpp

249

Reminds me that I should revive my old patch of being able to construct patterns inline when adding them to the rewriter.

273

That is how I originally had it, but it felt slightly weird. Moved it back.

[lattner]

mlir/include/mlir/IR/BuiltinOps.td

231

Ok, but you can't have it both ways. If it has side effects, you should drop the canonicalization that removes unused casts.

I don't really understand this design point though. it is the result of a partial conversion. These things are doomed to go away. How can they have side effecting semantics? Can you give an example that would illustrate this? If you can, does it need to be handled by this instead of some other dialect specific op?

248

Makes sense, how about making the example something that would show this then, e.g.:

%result = partial_conversion_cast to !mylanguage.tuple<>

and mention explicitly that this can be useful for things where you can have empty tuples.

[rriddle]

mlir/include/mlir/IR/BuiltinOps.td

231

Yeah, I don't have a strong motivating example. I'm okay with marking it as non-side effecting and letting users that really need to preserve something add their own proper cast operation, which is probably what they should be doing in those cases anyways.

[lattner]

+1, thanks River

[herhut]

I don't mind adding this generic default cast but I hope dialect conversion will remain configurable as to which cast is being used.

mlir/include/mlir/IR/BuiltinOps.td

231

I would be in favour of marking it nosideeffect, as well. After all, these casts often just disappear and I always found it odd that dialect conversion might make them disappear if they are unused but if that did not happen, dcr would not. Also, there is very little guarantee where they get inserted in the first place (unless we want to specify this and nail it down), so relying on the casts exact placement seems dangerous.

251

Wouldn't that be partial_cast <operands> : <srctypes> to <dsttypes>?

partial_cast : () to (t1, t2)
partial_cast %v0 : t0 to t1
partial_cast %v0 : t0 to (t1, t2)
partial_cast %v0, %v1 : (t0, t1) to (t2)

I don't mind either syntax but if consistency is the argument, it should be close to what we have.

[rriddle]

Address feedback

mlir/include/mlir/IR/BuiltinOps.h

 
 #ifndef MLIR_IR_BUILTINOPS_H_
 #define MLIR_IR_BUILTINOPS_H_
 
 #include "mlir/IR/FunctionSupport.h"
 #include "mlir/IR/OwningOpRef.h"
 #include "mlir/IR/SymbolTable.h"
 #include "mlir/Interfaces/CallInterfaces.h"
+#include "mlir/Interfaces/CastInterfaces.h"
+#include "mlir/Interfaces/SideEffectInterfaces.h"
 #include "llvm/Support/PointerLikeTypeTraits.h"
 
 //===----------------------------------------------------------------------===//
 // Dialect Operations
 //===----------------------------------------------------------------------===//
 
 #define GET_OP_CLASSES
 #include "mlir/IR/BuiltinOps.h.inc"

mlir/include/mlir/IR/BuiltinOps.td

 //===----------------------------------------------------------------------===//
 
 #ifndef BUILTIN_OPS
 #define BUILTIN_OPS
 
 include "mlir/IR/BuiltinDialect.td"
 include "mlir/IR/SymbolInterfaces.td"
 include "mlir/Interfaces/CallInterfaces.td"
+include "mlir/Interfaces/CastInterfaces.td"
+include "mlir/Interfaces/SideEffectInterfaces.td"
 
 // Base class for Builtin dialect ops.
 class Builtin_Op<string mnemonic, list<OpTrait> traits = []> :
     Op<Builtin_Dialect, mnemonic, traits>;
 
 //===----------------------------------------------------------------------===//
 // FuncOp
 //===----------------------------------------------------------------------===//
]> {
   let description = [{
     `module_terminator` is a special terminator operation for the body of a
     `module`, it has no semantic meaning beyond keeping the body of a `module`
     well-formed.
   }];
   let assemblyFormat = "attr-dict";
 }
 
+//===----------------------------------------------------------------------===//
+// UnrealizedConversionCastOp
+//===----------------------------------------------------------------------===//
+
+def UnrealizedConversionCastOp : Builtin_Op<"unrealized_conversion_cast", [
+    DeclareOpInterfaceMethods<CastOpInterface>, NoSideEffect
+  ]> {
+  let summary = "An unrealized conversion from one set of types to another";
+  let description = [{
+    An `unrealized_conversion_cast` operation represents an unrealized
+    conversion from one set of types to another, that is used to enable the
+    inter-mixing of different type systems. This operation should not be
+    attributed any special representational or execution semantics, and is
+    generally only intended to be used to satisfy the temporary intermixing of
+    type systems during the conversion of one type system to another.
+
+    This operation may produce results of arity 1-N, and accept as input
+    operands of arity 0-N.
+
+    Example:
+
+    ```mlir
+    // An unrealized 0-1 conversion. These types of conversions are useful in
+    // cases where a type is removed from the type system, but not all uses have
+    // been converted. For example, imagine we have a tuple type that is
+    // expanded to its element types. If only some uses of an empty tuple type
+    // instance are converted we still need an instance of the tuple type, but
+    // have no inputs to the unrealized conversion.
+    %result = unrealized_conversion_cast to !bar.tuple_type<>
+
+    // An unrealized 1-1 conversion.
+    %result1 = unrealized_conversion_cast %operand : !foo.type to !bar.lowered_type
+
+    // An unrealized 1-N conversion.
+    %results2:2 = unrealized_conversion_cast %tuple_operand : !foo.tuple_type<!foo.type, !foo.type> to !foo.type, !foo.type
+
+    // An unrealized N-1 conversion.
+    %result3 = unrealized_conversion_cast %operand, %operand : !foo.type, !foo.type to !bar.tuple_type<!foo.type, !foo.type>
+    ```
+  }];
+
+  let arguments = (ins Variadic<AnyType>:$inputs);
+  let results = (outs Variadic<AnyType>:$outputs);
+  let assemblyFormat = [{
+    ($inputs^ `:` type($inputs))? `to` type($outputs) attr-dict
+  }];
+  let hasFolder = 1;
+}
+
 #endif // BUILTIN_OPS

mlir/lib/IR/BuiltinDialect.cpp

 
 #include "mlir/IR/BuiltinDialect.h"
 #include "mlir/IR/BlockAndValueMapping.h"
 #include "mlir/IR/Builders.h"
 #include "mlir/IR/BuiltinOps.h"
 #include "mlir/IR/BuiltinTypes.h"
 #include "mlir/IR/FunctionImplementation.h"
 #include "mlir/IR/OpImplementation.h"
+#include "mlir/IR/PatternMatch.h"
 #include "llvm/ADT/MapVector.h"
 
 using namespace mlir;
 
 //===----------------------------------------------------------------------===//
 // Builtin Dialect
 //===----------------------------------------------------------------------===//
 
if (!attr.first.strref().contains('.') &&
                                  "dialect-prefixed names, found: '"
                               << attr.first << "'";
   }
 
   return success();
 }
 
 //===----------------------------------------------------------------------===//
+// UnrealizedConversionCastOp
+//===----------------------------------------------------------------------===//
+
+LogicalResult
+UnrealizedConversionCastOp::fold(ArrayRef<Attribute> attrOperands,
+                                 SmallVectorImpl<OpFoldResult> &foldResults) {
+  OperandRange operands = inputs();
+  if (operands.empty())
+    return failure();
+
+  // Check that the input is a cast with results that all feed into this
+  // operation, and operand types that directly match the result types of this
+  // operation.
+  ResultRange results = outputs();
+  Value firstInput = operands.front();
+  auto inputOp = firstInput.getDefiningOp<UnrealizedConversionCastOp>();
+  if (!inputOp || inputOp.getResults() != operands ||
+      inputOp.getOperandTypes() != results.getTypes())
+    return failure();
+
+  // If everything matches up, we can fold the passthrough.
+  foldResults.append(inputOp->operand_begin(), inputOp->operand_end());
+  return success();
+}
+
+bool UnrealizedConversionCastOp::areCastCompatible(TypeRange inputs,
+                                                   TypeRange outputs) {
+  // `UnrealizedConversionCastOp` is agnostic of the input/output types.
+  return true;
+}
+
+//===----------------------------------------------------------------------===//
 // TableGen'd op method definitions
 //===----------------------------------------------------------------------===//
 
 #define GET_OP_CLASSES
 #include "mlir/IR/BuiltinOps.cpp.inc"

mlir/lib/IR/CMakeLists.txt

add_mlir_library(MLIRIR
   ADDITIONAL_HEADER_DIRS
   ${MLIR_MAIN_INCLUDE_DIR}/mlir/IR
 
   DEPENDS
   MLIRBuiltinDialectIncGen
   MLIRBuiltinOpsIncGen
   MLIRBuiltinTypesIncGen
   MLIRCallInterfacesIncGen
+  MLIRCastInterfacesIncGen
   MLIROpAsmInterfaceIncGen
   MLIRRegionKindInterfaceIncGen
+  MLIRSideEffectInterfacesIncGen
   MLIRSymbolInterfacesIncGen
 
   LINK_LIBS PUBLIC
   MLIRSupport
   )

mlir/test/Dialect/Builtin/canonicalize.mlir

+// RUN: mlir-opt %s -canonicalize | FileCheck %s
+
+//===----------------------------------------------------------------------===//
+// UnrealizedConversionCastOp
+//===----------------------------------------------------------------------===//
+
+// Test folding conversion casts feeding into other casts.
+// CHECK-LABEL: func @multiple_conversion_casts
+// CHECK-SAME: %[[ARG0:.*]]: i32, %[[ARG1:.*]]:
+func @multiple_conversion_casts(%arg0: i32, %arg1: i32) -> (i32, i32) {
+  // CHECK-NOT: unrealized_conversion_cast
+  // CHECK: return %[[ARG0]], %[[ARG1]]
+  %inputs:2 = unrealized_conversion_cast %arg0, %arg1 : i32, i32 to i64, i64
+  %outputs:2 = unrealized_conversion_cast %inputs#0, %inputs#1 : i64, i64 to i32, i32
+  return %outputs#0, %outputs#1 : i32, i32
+}
+
+// CHECK-LABEL: func @multiple_conversion_casts
+func @multiple_conversion_casts_failure(%arg0: i32, %arg1: i32, %arg2: i64) -> (i32, i32) {
+  // CHECK: unrealized_conversion_cast
+  // CHECK: unrealized_conversion_cast
+  %inputs:2 = unrealized_conversion_cast %arg0, %arg1 : i32, i32 to i64, i64
+  %outputs:2 = unrealized_conversion_cast %arg2, %inputs#1 : i64, i64 to i32, i32
+  return %outputs#0, %outputs#1 : i32, i32
+}

mlir/test/Dialect/Builtin/invalid.mlir

+// RUN: mlir-opt %s -split-input-file -verify-diagnostics
+
+//===----------------------------------------------------------------------===//
+// UnrealizedConversionCastOp
+//===----------------------------------------------------------------------===//
+
+// expected-error@+1 {{expected at least one result for cast operation}}
+"unrealized_conversion_cast"() : () -> ()
+
+// -----
+

mlir/test/Dialect/Builtin/ops.mlir

+// RUN: mlir-opt %s -allow-unregistered-dialect | mlir-opt -allow-unregistered-dialect
+
+//===----------------------------------------------------------------------===//
+// UnrealizedConversionCastOp
+//===----------------------------------------------------------------------===//
+
+%operand = "foo.op"() : () -> !foo.type
+%tuple_operand = "foo.op"() : () -> !foo.tuple_type<!foo.type, !foo.type>
+
+// An unrealized 0-1 conversion.
+%result = unrealized_conversion_cast to !bar.tuple_type<>
+
+// An unrealized 1-1 conversion.
+%result1 = unrealized_conversion_cast %operand : !foo.type to !bar.lowered_type
+
+// An unrealized 1-N conversion.
+%results2:2 = unrealized_conversion_cast %tuple_operand : !foo.tuple_type<!foo.type, !foo.type> to !foo.type, !foo.type
+
+// An unrealized N-1 conversion.
+%result3 = unrealized_conversion_cast %operand, %operand : !foo.type, !foo.type to !bar.tuple_type<!foo.type, !foo.type>