[Mlir-commits] [mlir] [mlir][tensor] Preserve encoding in more canonicalizers (concat, reshape, pad) (PR #207241)

[Dmitrii Makarenko]

Devjiu wrote:

@joker-eph

Ok, thanks for the clarification. Sorry, I didn't want to skip this issue; I thought that static verification could be sufficient. I think this actually splits into two very different situations, and I think conflating them is where the "inconsistency" comes from.

**Category 1** - patterns that only insert/fold a `tensor.cast` and never change the runtime value: `InsertSliceOpConstantArgumentFolder`, `ConvertToStaticExpandShape`, `FoldSourceTensorCast`. These recover static knowledge about a tensor whose actual shape never changes - the cast target describes the *same* runtime tensor, just more precisely. If an encoding was valid for that tensor before, it's valid after, unconditionally - no verify call needed, because nothing about the value changed, only what the compiler knows about it. I think unconditional propagation is actually
correct here, not a heuristic.

**Category 2** - patterns where the op genuinely transforms data: `CollapseShapeOp` (rank change), `ConcatOp` (merges tensors), `PadOp` (adds elements). Here the shape really does change, and you're right that `verifyEncoding` can't reliably answer whether the encoding still holds when the new shape has dynamic dims - it can only catch what's statically
provable, which is exactly the gap you're pointing at with the concat example.

For category 2 I don't have a fully general answer - bailing out when an encoding is present is one option, though it also disables refinement for cases that would've been fine. 

Would it help to split the scope along these lines: land category 1 here (this PR, `InsertSliceOpConstantArgumentFolder`/`ConvertToStaticExpandShape`/ `FoldSourceTensorCast`) with unconditional propagation, and keep category 2 (`CollapseShapeOp`, `ConcatOp`, `PadOp`, tracked separately) open for
further discussion - possibly landing on bail-out there if we can't find something better?



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