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

[Andrei Golubev]

andrey-golubev wrote:

> The sole purpose of why the convert-to-attribute path was included in the development of properties was for the purpose of the generic printer (IIRC). So I am not sure what it would mean to add an escape hatch here really: if we were to accept this then the convert-to-attribute may just go away instead.

I think this could be a good way out, actually. Let me look at it a bit more, perhaps i'll see how to make it work. I'd ideally want to avoid large refactorings, though, which is why I went with "OK, I can do a hook here and all is good" approach :) (most of the infra - even the hook - was already present even).

> What is the reasoning behind this and could this be solved some other way maybe?

Do you mean why it happens or why I want to avoid this?
* Why it happens: if there's a "broken" IR (e.g. verifier doesn't succeed), then the printing would assume all-bets-are-off and switch to a generic (read "safer") mode. At least that's the way I understand the reasoning for this. Usual scenarios where it could be important is during debugging, some missed-at-validation bugs, etc. The last thing I want is for the users of my properties to fail with a hard error (e.g. I would ideally unconditionally assert or throw from "convert-to-attribute" / "convert-from-attribute" APIs) so the other extreme is to actually support the thing until it's removed (if at all, though? - but I think it should be because, as stated in the commit message, "you can convert a property to attribute" kind of implies "you can print this property"?)
* Why to avoid: property -> attribute breaks the "property silo". As properties were introduced to "not store objects forever in context's memory", having to do conversions means going against this idea. Also, if the facility only exists for the sake of printing / parsing, it's like having to maintain a half-dead code that's still there for "that one case". I could be wrong here but I don't think our downstream ever uses generic printing feature, which is why I don't really interpret it as a "first-class citizen". I think if we just go with "default-created properties should be printable" invariant, this would give us the guarantees we want without needing to invent attributes for properties.

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