[Mlir-commits] [mlir] Enable printing newlines and indents in attribute and type printers (PR #87948)

Jacques Pienaar llvmlistbot at llvm.org
Sat Aug 16 01:12:25 PDT 2025


jpienaar wrote:

This enables querying indentation. Attributes can already print multiline and make their parsers handle it, not that it documented as supported nor widely used. I think my main concern would be that such multiline attributes can obscure program structure (e.g., one goes from a form where most operations are single line, to one where it is variable, and knowing if a line is part of attribute or operation may require going 100 lines up or down to find start/end). And in which case emitting as aliases always is much better, and if emitted always as an alias, one knows exactly the indent already and this is not needed (e.g., dialect can check size of output, if large use alias, else no alias, and based on same size attribute can print indented or not).

This would enable making it prettier for the non-alias case. But by making it an explicit option, this does move from possible to supported use. I do want a multiline string constant and it does help a lot for such cases where it isn't large. Does seem useful, but can be abused and make the IR less useful.

Having it be context sensitive (e.g., inside alias or not, inside op that opt'd in or not) is not something we have today. I was thinking about the raw_indented_ostream and potential of swapping out indenting/newline output (e.g., if a regular raw_indented_ostream then its nested, if not its flattened) as a mechanism. But it would be the first time we have such a case ... well, no, that's not true: an operation can always decide to print and parse the attribute however it wishes, its only when it just delegates to attribute kind where that isn't true (that just happens to be the case >90% of the time!). And code duplication can be avoided c++ side.

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


More information about the Mlir-commits mailing list