Please mark as NFC in the commit message.

https://buildkite.com/llvm-project/premerge-checks/builds/74313#bc3eefd3-52f4-4d4b-beed-0c2a170d22f5 now shows 1 unrelated failure:

https://buildkite.com/llvm-project/premerge-checks/builds/74313#bc3eefd3-52f4-4d4b-beed-0c2a170d22f5 now shows 1 unrelated failure:

Rebase.

Drop old tests.

Rebase post revert.

hmm sorry .. the build was green but it seems I made a mistake landing and ended up squashing 2 things that turned into a breakage.
Thanks @mehdi_amini

Address and rebase.

Rebase.

Rebase.

This was folded and merged into c8f5735301993c363c16ce5ddda6f1f6cb968090 during a rebase.

Rebase

Please update the commit message to reflect your latest changes, thanks!

Ah this already happens transitively, LGTM, thanks @bkramer !

Can we make proper use of this new function also in the reshape op verifiers?
We should have only one logic used everywhere.
Thanks for pushing on this cleanup!

Rebase and address

Note: I am sending a rewrite of the extract from insert+transpose chain that needs more cases than we currently have.
Would be good to also have the same extensions for this revision.

@aartbik is actually the original contributor of this abstraction and the main user at this time.
Offhand it would seem to me that we wouldn't want negative values here?
I would personally rather go for an explicit truncation, but @aartbik will know better.

thanks, you may want to look at other linalg.copy canonicalizations and foldings that may have been missed when memref.copy was introduced.

We had a deeper offline discussion with @bkramer
There is a bug that needs to be fixed.
In the same way that we have a "isCastCompatible", we should have a "isShapeCollapse/Expand" compatible.
In this form, the result of that "isShapeCollapse/Expand" is false and the pattern/transformation should fail to apply.

Please leave a TODO somewhere that you can improve this to making 0 or 1 copies (e.g. dynamically if you put your copy operations under the same conditional as the switch; or something else as we discussed offline).
Atm you make 0, 1 or 2 copies quite greedily.

I don't see a particular semantic problem with either cases (fully static, partially static, fully dynamic): all are valid and are subject to the same UB as a wrong cast would be.
I think Mahesh's suggestion is better because there is no guarantee in shape reification that you'd return 1 and you may well end up with propagating dynamic information further down.
I wouldn't change the verifier behavior here as it could limit the ability to have partial foldings that I think are valid.

Nice, thanks much!

Reasbe , clean

Rebase address and cleanup

One note is to add comments/doc re what is a heuristic and how combining with "reuse any opoperand" type of heuristic may create undesirable cases (e.g. the constant case).

This is also related to D115706 (cc @silvas).

Note: during the peer-review session we identified the fat that this current impl pushes bufferization further into "destination-passing style"-land and that we may want to generalize in the future (e.g. this cannot work with the torch-mlir as is).
We discussed that we could alternatively:

1. pick any dominating tensor in the program (not just an op operand) as a candidate for "inplace"
2. perform SSA use-def analysis on that tensor
3. use it as the result

This would support something like %c = torch.mm(%a, %b) while avoiding to materialize a new %c for each op.

Side note: I think we could also drop memref.view and just use this instead.
This would be a good starter task.

Nice cleanup!

Rebase.

Add expander helpers.