[Mlir-commits] [mlir] [mlir] Add dialect hooks for registering custom type and attribute alias printers (PR #173091)
Fabian Mora
llvmlistbot at llvm.org
Mon Dec 22 10:59:06 PST 2025
fabianmcg wrote:
> Otherwise as Jacques mentioned, suddenly the printed IR depends on the dialects that are loaded, that means that printing the same IR before or after running a pass-pipeline (on an unrelated IR) would change the printing.
>
> It's also not clear to me if your chaining of callbacks provides a unambiguous resolution of the printing right now: the ordering in which dialects are loaded could then impact the printed IR.
This is already the state for the current alias system with `OpAsmDialectInterface`. If the argument is, the current system has mistakes and either we should remove it, or we need to tighten constraints then I can understand a bit more the rationale behind the argument.
Now, some those concerns can be alleviated and fixed. For example, by imposing the constraint that it's only allowed to alias entities that are guaranteed to have loaded the dialect imposing the alias. For example, `!ptr.ptr<#llvm.address_space<x>>` guarantees `llvm` is already loaded.
> > We already allow text sugaring to hide bits of the internal state. For example, we don't always print attr_segment_sizes.
>
> I don't quite see the relationship though.
The faithfulness of the representation with pretty printing is already blurred. As there are hidden states that are not printed. Now, this mechanism does indeed blurs the line a bit more as the hidden state might point to a dependent dialect. But my point is, the pretty syntax is already hiding information.
FWIW. There's a more limited implementation https://github.com/llvm/llvm-project/pull/86033, that scopes dialect aliases to particular types and attributes, where none of the ordering issues happen. However, last time I was asked to generalize towards the path in this patch.
https://github.com/llvm/llvm-project/pull/173091
More information about the Mlir-commits
mailing list