[Mlir-commits] [mlir] [MLIR][Transform] Don't error when a structurally inlinable call exists (PR #195770)

[Martin Paul Lücke]

martin-luecke wrote:

I think the invariant from #192956 is narrower than the current implementation.

The merge can affect `transform.include` because it moves/merges symbol definitions that the include resolves to. So the relevant thing to validate is whether transform include edges that participate in named-sequence inlining are still legal after merging.

I don’t think transform-library merging should impose an invariant on arbitrary non-transform dialect calls under the same symbol table. In the interpreter path, `mergeSymbolsInto` is called with `SymbolTable::getNearestSymbolTable(transformRoot)`, which can be the whole `builtin.module` containing the embedded transform IR and unrelated sibling IR.

For example:

```mlir
module attributes {transform.with_named_sequence} {
  transform.named_sequence @__transform_main(%arg0: !transform.any_op) {
    transform.yield
  }

  func.func @f() {
    return
  }

  func.func @main() {
    call @f() {no_inline} : () -> ()
    return
  }
}
```

Here the `func.call` is sibling IR under the same module, not a `transform.include`. Whether it is inlineable is unrelated to transform-library merging, and the old full verifier did not enforce that either.

So this PR fixes the immediate regression, but I agree the underlying check is broader than the invariant it is meant to protect. We will address this in a follow-up by narrowing the post-merge legality check to transform named-sequence/include edges instead of all CallOpInterface ops under the symbol table.

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