[Mlir-commits] [mlir] [mlir][vector] Always print the in_bounds attribute (PR #96031)

[Andrzej Warzyński]

banach-space wrote:

> > This makes testing certain behaviours impossible (i.e. to make sure that the attribute is correctly preserved/transformed
> > by patterns that modify it).
> 
> I didn't quite get this part?

Take this example:
```mlir
func.func @xfer_write_transposing_permutation_map_out_of_bounds(
    %arg0: vector<4x8xi16>,
    %mem: memref<2x2x?x?xi16>) {

  %c0 = arith.constant 0 : index
  vector.transfer_write %arg0, %mem[%c0, %c0, %c0, %c0] {
    in_bounds = [false, false],
    permutation_map = affine_map<(d0, d1, d2, d3) -> (d3, d2)>
  } : vector<4x8xi16>, memref<2x2x?x?xi16>

  return
}
```

Under `TransferWritePermutationLowering`, it's rewritten as:
```mlir
  func.func @xfer_write_transposing_permutation_map_out_of_bounds(%arg0: vector<4x8xi16>, %arg1: memref<2x2x?x?xi16>) {
    %c0 = arith.constant 0 : index
    %0 = vector.transpose %arg0, [1, 0] : vector<4x8xi16> to vector<8x4xi16>
    vector.transfer_write %0, %arg1[%c0, %c0, %c0, %c0] : vector<8x4xi16>, memref<2x2x?x?xi16>
    return
  }
```

The transformation is safe, but we can't verify that `in_bounds = [false, false]` was preserved if it's not printed.  That's what I'm trying to fix here. Hope this answers your question - let me know if not.

> 
> > Separately, it's not clear whether the absence of the in_bounds attribute in the printed IR is meant to mean that: [...]
> 
> This is a design problem: optional attributes shouldn't mean the same thing as a "default valued" one. Here a possible fix to remove the ambiguity could also be to make it non-optional (but default valued).

This would also be an improvement. I'm happy to take this route if that's the preference. I'd do it in a follow-up PR though (if that's OK)

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