[Mlir-commits] [mlir] [mlir][AsmPrinter] Print op properties directly in generic form (PR #106996)

[River Riddle]

River707 wrote:

> > One thing that has been in mind though, why not change properties to just preserve the string form the same way we do for UnknownAttr/UnknownType when the op isn't registered?
> 
> Could you elaborate? I think I'm out of context here. Is the main problem in _parsing_? I.e. if we end up having unregistered operation, we go through [UnregisteredOpModel](https://github.com/llvm/llvm-project/blob/fe1a1eee2ff864d2ba00ad67e6360b7178e67d5c/mlir/include/mlir/IR/OperationSupport.h#L194) and that one has to store properties in some form (now, as a dict attr I guess) until we load all the necessary info and are able to "restore" concrete C++ objects (aka properties)? If you could point me to the places of interest in code, it would be nice, maybe that way I'd have a better idea (or maybe there are tests).

Yes, the problem is parsing things back in when you don't have anything registered. When we print, we shouldn't technically need to convert to an attribute (that's just how it works right now). For Types and Attributes, we always print them using the registered hooks. When parsing, if the dialect isn't registered we create UnknownAttr or UnknownType, which effectively just hold the dialect name and the raw string that we parsed from the source .mlir file. Take a look at the parser code for [Attributes](https://github.com/llvm/llvm-project/blob/5e1e6a689c82aaf2b7af72e074c95889a11d3a78/mlir/lib/AsmParser/DialectSymbolParser.cpp#L277) and [Types](https://github.com/llvm/llvm-project/blob/5e1e6a689c82aaf2b7af72e074c95889a11d3a78/mlir/lib/AsmParser/DialectSymbolParser.cpp#L318). Handling things this way enables for roundtripping attributes/types in unregistered dialects as a "pass through" effectively. For properties I would hope we could do the same thing: When parsing a property dictionary for an unregistered operation, store the full parsed string. When printing we just splat it back out (so from a textual perspective it generates the same thing exactly).

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