[Mlir-commits] [mlir] [MLIR][DLTI] Make queries visit all ancestors/respect nested scopes (PR #115043)

[Rolf Morel]

rolfmorel wrote:

This PR introduces the most straightforward look-up semantics: just continue traversing outer scopes, i.e visiting ancestor ops, until a multi-key query succeeds in full on a DLTI attribute on one of the ancestor ops of the `target` op. 

This look-up semantics implies that it is not possible to "hide" names that have been defined in DLTI attributes on ancestor ops. Pretty standard, actually. However, as the following is allowed in syntax we might want to ponder what it should mean:
```
module attributes { test.dlti = #dlti.map<"CPU" = #dlti.map<"tile_size" = 64, "pad_to" = 16>> } {
  func.func @f(%A: tensor<128x128xf32>) attributes { test.dlti = #dlti.map<"CPU" = {}> } {
    linalg.matmul { test.dlti = #dlti.map<"CPU" = #dlti.map<"tile_size" = 24 : i32>> } ...
    arith.constant 0 : i32
    return
  }
  func.func @g() {
    ...
  }
}
```

Given that the user "overrode"/shadowed the "leading" key `"CPU"` with the non-DLTI attribute `{}`, what consequence should this have for attempting to query keys `["CPU","pad_to"]` at the `linalg.matmul` inside `@f`? And what about queries at `arith.constant` inside `@f`?

With the PR as is the answer to `query(%handle_to_matmul, ["CPU","pad_to"])` is `16` and `query(%handle_to_matmul, ["CPU","tile_size"])` is 24 and `query(%handle_to_constant, ["CPU","pad_to"])` is `16` as well and `query(%handle_to_constant, ["CPU","tile_size"])` is 64.

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