[Mlir-commits] [mlir] [mlir] Add dialect hooks for registering custom type and attribute alias printers (PR #173091)

[Fabian Mora]

================
@@ -0,0 +1,14 @@
+// RUN: mlir-opt %s | FileCheck %s
+
+// Check that attr and type aliases are properly printed.
+
+// CHECK: {types = [!test.tuple_i7_from_attr, !test.tuple_i6_from_attr, tuple<!test.int<signed, 5>>]} : () -> (!test.tuple_i7, !test.tuple_i6, tuple<!test.int<signed, 5>>)
+"test.op"() {types = [
----------------
fabianmcg wrote:

Ok there are multiple layers to this.

Strictly speaking, even without this change one can add logic in any dialect (ie. no upstream changes) to parse `!dialect-prefix.body` and construct a type that is in the dependent dialect set. In other words, I could do something like `!foo.type<x>` and return `!bar.my_type<x>`. One just needs to modify `[parseType](https://mlir.llvm.org/doxygen/classmlir_1_1Dialect.html#a263eb7749b177663efac29f146b723d8)`.
Therefore, all the required infrastructure for dialect aliases for parsing is already upstream.

However, this is not the case for printing. Consequently, this patch only resolves this asymmetry, and allows to do the same for printing. This is why above I said, this patch doesn't affect parsing behavior.

Within this patch, it's not possible to parse `!test.tuple_i7_from_attr` as I didn't add the C++ logic in the test dialect to parse that. The reason I didn't do it, is because I'm not adding anything to modify the parsing logic.
I can easily add the logic and make the IR roundtripable.

It's also future work to automatically generate parsing and printing dialect alias logic from ODS.

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