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

[Jacques Pienaar]

jpienaar wrote:

Standalone and rountripable is required I think. These two kinds of aliases are rather different for me though, can't come up with good naming though ... Writing out thoughts below.

Re: asymmetry. I don't actually see it as asymmetry, I see it as a dialect can dictate how it parses "its" operations, attributes/type, aliases. This is desirable and expected. So parsing it from one dialect and creating an in memory form using another, I find that no worse than createOrFold. I'd be open to making that documented as WAI as it still goes towards how ops can parse attributes in different formats (e.g., an int attribute can have a different textual format on different ops). And it's dictated by the op's printer/parser which is WAI. Which is what I don't like here, dialect B shouldn't be able to dictate how dialect A is printed.

Stepping up. Conceptually here, we are saying LLVM dialect is a dialect that consists of the PTR dialect (e.g., it consists of ops and the other dialect). For composition I'd expect:
1. One can parse in multiple formats;
    1. This is effectively that a dialect can opt-in to parse a type as an alias and/or dialects can have a virtual attribute/type that's just that of another;
2. One can print multiple formats;
    1. I'd expect this to be fixed per op, tool or per dialect (e.g., in LLVM dialect, printing PTRs could differ, but ptr independently would not);
3. isa/dyn_cast etc works equally across both and it shouldn't matter;
    1. Its just an alias - now of course if it isn't just an alias, then one would only sometimes correspond to the other, so you'd have different behavior;
    2. If one just parses to dialect B's in memory, this is a given;
    3. One could have different convenience members on aliased one (that is a view on a view);

So I would have expected that LLVM could still parse ptr's as it did before, in memory it would be changed sure and it would change on roundtrip sure. That's not different from aliases today. This is just having parsing for LLVM dialect to PTR, but no change in printer. And that's already possible.

For changing printer, if one wanted to enable changing, I think that would introduce contextual printing. That's not really too difficult. It means one has a hook to intercept printing types that's consulted before the default. It is more overhead though - although could be done to be not much different than today (push and pop kind on map kind). It means the dialect whose op is being printed (or, potentially, whose op one is nested in) could have different intercepts. So an attribute can be printed uniformly different for all ops on that dialect. This is no different from how an op can print a different format today except it is generalized to cover all cases in dialect not specialized by the op (e.g., its not test.foo dictating how IntegerAttr is printed but also dialect test that can opt in for all _its_ ops a way to print attr/type).

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