[Mlir-commits] [mlir] [mlir][python] Add normalforms to capture preconditions of transforms (PR #79449)

[llvmlistbot at llvm.org]

martin-luecke wrote:

The question is how much lifting the bindings are allowed to do to make IR generation easier. 
In my opinion, these are convenience extras to help generate transform IR more easily. 
No analysis or transformation of existing IR is happening here.

The goal is for instance to be able to write
```python
with Context(), InsertionPoint(body), Autonormalize(): 
  matmul = module.match_op(linalg.matmulOp)
  matmul.tile(tile_sizes=[4,8])
```
instead of:
```python
with Context(), InsertionPoint(body): 
  matmul = module.match_op(linalg.matmulOp)
  module.apply_tiling_canonicalization()
  module.apply_licm()
  module.canonicalize()
  matmul.tile(tile_sizes=[4,8])
```
to generate similar IR.

I think the Python bindings have slowly transitioned into more than bindings. Rather than simply exposing the C++ API to Python, they provide sensible pythonic frontend abstractions. 
For instance, we can annotate Python functions to generate `func.func` operations with an automatically inserted `func.return` for the SSA values returned from the _Python_ function, rather than calling into C++ APIs explicitly for this. 
AFAIK the C++ Dialect APIs are not concerned with easing IR emittance beyond OpBuilders. Abstractions that automatically inject ops are in Python only and improve usability there a lot.
Similar to other Python abstractions, I don't think this is designed as a feature that makes Python a non-optional component for transform dialect. 

The feedback about this at the LLVM devmtg was encouraging and to me, they did not feel out of place in this environment of "easing IR generation" so I started upstreaming.

Would you be happier with this feature if we had it in C++ as well or even found a way to encode this in the IR?

Of course, if there are objections to such extras I will take this down.

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