[Mlir-commits] [mlir] [mlir][tensor] Make tensor::PadOp a ReifyRankedShapedTypeOpInterface and add a PadOp::FoldReifiedShape canonicalization (PR #145732)

[Nicolas Vasilache]

nicolasvasilache wrote:

@MaheshRavishankar @matthias-springer I think we may need a longer alignment session here but TL;DR my position atm is:

- it is not a problem to create new IR in canonicalization patterns as long as it can be cleaned up with a scope guard on failure. There is a world of difference between creating eventually unused IR that we can clean up and putting the IR in an invalid state.
- re. what should and should not be a canonicalization: there is generally not "a canonicalization" but a multitude of normal forms whose lattice is not well defined and whose effects on "system entropy" are really unclear. However, folding dynamic into static dimensions is always fair game in my book.

If I wanted to be creative I could slash at the APIs to make this not generate IR and just pop out the constants (I am unsure the API changes will be desired though). However the `tensor.cast` is still needed to make types agree and has to propagate forward, so it can never become a true folder. 

Taking the extreme opposite view, I would ask why is a tesor/memref.CastOp ever considered a canonicalization?
The answer would be the same: more static information => lower entropy in the IR.

In general, looking at these issues more deeply after 2y, I like how the reification APIs and interfaces have evolved.
But I find there is a big gap between their existence and their use.
I think we are missing a lot of opportunities for rewrites that discover static information in the IR and turn ? into constants.

This is all "modulo compiler cost"; I did not go as far as putting ValueBoundsOpInterface part of canonicalization but I would claim we should have an "expensive canonicalization" or something rather than have to discover a set of transforms that need to be applied together for this purpose of finding more static information.

To further supplement my point, I'll claim that a lot of the static behavior that we enjoy today comes from `makeComposedFoldedAffineApply` + `DimOp`/`reifyStuff` folding.
The first one is applied pervasively, the second is not and I'd argue we would want to make it much more pervasive.

Anyway, not trying to start an RFC in a PR or an ODM but a discussion on "is making shapes more static" a canonicalization and "creating IR that can be reverted" would be useful principles to have a general agreement on.

@joker-eph @rengolin @ftynse for their take too.

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