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

[Dmitrii Makarenko]

Devjiu wrote:

@joker-eph

Good point, and I think the code already does exactly what you're describing - for the patterns that fold an existing cast.

`FoldSourceTensorCast`, `ConvertToStaticExpandShape`, `FoldCollapseOfCastOp` all gate on `canFoldIntoConsumerOp` -> `preservesStaticInformation`, which requires the cast's source and target to have the *same* encoding:

```cpp
// Requires same encoding.
if (sourceType.getEncoding() != targetType.getEncoding())
  return false;
```

So the two situations are mutually exclusive: 
if a cast erases the encoding (source has it, target doesn't), the encodings differ, the gate returns false, and the cast is left in place - the erasure is preserved, exactly as you want. 

The fold only applies when both sides already carry the same encoding, i.e. when nothing was erased and there's nothing to respect. I confirmed this: a `tensor.cast` dropping the encoding in front of a tensor.pad is untouched by canonicalization.

That leaves `InsertSliceOpConstantArgumentFolder`, which is a different shape: there's no incoming cast at all - it applies because one of the `mixedSizes` became constant, and inserts a new cast from the original source operand. There's no prior erasure to respect, so propagating the source's own encoding is the only correct choice.

So maybe the split isn't category-1-vs-2 by "changes runtime value", but:
- fold-an-existing-cast patterns: already correct via `preservesStaticInformation` (same-encoding requirement), no change needed;
- insert-a-new-cast patterns (`InsertSliceOpConstantArgumentFolder`): propagate the operand's encoding, since there's no prior cast to defer to.

Does that reframing address the concern?

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