feat(printer): declarative assembly-format DSL + custom (pretty) printing

[GZGavinZhao]

Add a TableGen-style declarative assembly-format DSL for printing operations in their custom (pretty) syntax, currently gated behind the --pretty flag.

Currently three examples are given:

• func.return and func.call using the declarative syntax, mirroring the TableGen's declarative syntax.
• func.func uses a dedicated printer hook, mirroring MLIR's hasCustomAssemblyFormat.

Parsing of pretty syntax is added in a follow-up; this PR only changes printing, so the default (generic) output and all existing tests are unaffected.

TBD: document where exactly our format is different from the upstream TableGen syntax. Documented in the header comment of Veir/AssemblyFormat.lean. Almost all of the difference comes from VeIR not having named operands/results for operations. To achieve true 1-1 mapping, we need some form of build-time (ideally run-time as well) map from an operation's field names to index/type.

[github-actions]

VeIR Benchmarks

Details

Benchmark suite	Current: 652e406	Previous: fc38e7f	Ratio
add-fold-worklist/create	1797000 ns (± 15811)	2227000 ns (± 44602)	0.81
add-fold-worklist/rewrite	3532000 ns (± 45417)	3985000 ns (± 90307)	0.89
add-fold-worklist-local/create	1796000 ns (± 51046)	2164000 ns (± 78738)	0.83
add-fold-worklist-local/rewrite	2987000 ns (± 42653)	3416000 ns (± 77796)	0.87
add-zero-worklist/create	1806000 ns (± 91059)	2223000 ns (± 100063)	0.81
add-zero-worklist/rewrite	2281000 ns (± 36148)	2522000 ns (± 106289)	0.90
add-zero-reuse-worklist/create	1530000 ns (± 19313)	1836000 ns (± 69049)	0.83
add-zero-reuse-worklist/rewrite	1873000 ns (± 26996)	2079000 ns (± 57582)	0.90
mul-two-worklist/create	1817500 ns (± 111210)	2236000 ns (± 102923)	0.81
mul-two-worklist/rewrite	5011500 ns (± 67179)	5561000 ns (± 111003)	0.90
add-fold-forwards/create	1803000 ns (± 11212)	2200000 ns (± 73638)	0.82
add-fold-forwards/rewrite	2645000 ns (± 17516)	3084000 ns (± 53148)	0.86
add-zero-forwards/create	1816500 ns (± 92492)	2251500 ns (± 139712)	0.81
add-zero-forwards/rewrite	1731000 ns (± 24866)	1978000 ns (± 47494)	0.88
add-zero-reuse-forwards/create	1517000 ns (± 57749)	1907500 ns (± 223419)	0.80
add-zero-reuse-forwards/rewrite	1380000 ns (± 51830)	1571500 ns (± 64613)	0.88
mul-two-forwards/create	1803000 ns (± 26178)	2270000 ns (± 141906)	0.79
mul-two-forwards/rewrite	3242000 ns (± 18262)	3747000 ns (± 113262)	0.87
add-zero-reuse-first/create	1545000 ns (± 47699)	1843500 ns (± 118926)	0.84
add-zero-reuse-first/rewrite	10000 ns (± 2641)	9500 ns (± 3036)	1.05
add-zero-lots-of-reuse-first/create	1553000 ns (± 15232)	1832000 ns (± 83852)	0.85
add-zero-lots-of-reuse-first/rewrite	793000 ns (± 30376)	801000 ns (± 40568)	0.99

This comment was automatically generated by workflow using github-action-benchmark.

[tobiasgrosser]

Nice. Let's see what @math-fehr says.

[AlexanderViand]

This looks really cool 👍

One (hopefully small) request: could you add an MLIR_ROUNDTRIP-style test that checks that the pretty-printed syntax veir-opt produces matches the real mlir-opt pretty print (i.e., each one can parse what the other prints, and the textual representation stays stable in the process)?

EDIT: Actually, I just tried the mlir->veir direction manually (mlir-opt Test/Func/pretty_syntax.mlir | lake exe veir-opt) and I think in order to make this work you'd also need to add pretty-printing for builtin.module:

<stdin>:1:1: error: operation expected
module {
^

So maybe this is more of a follow-up than something to deal with in this PR