Split out an EraseIdentityCopyOp from the existing RemoveIdentityLinalgOps pattern. Introduce an additional check to ensure the pattern checks the permutation maps match. This is a preparation step to specialize RemoveIdentityLinalgOps to GenericOp only.
The input and output operands are limited to memrefs in the op definition and the assertion is always true.
It is here since the canonicalization only makes sense in buffer land and it would be triggered if the op is modified to work on tensors (as most other structured operations). It thus encodes a necessary precondition to make the canonicalization correct.
The verification already checks the input and output operands are memrefs (they are of type AnyStridedMemRef). I think we are good there.
The purpose of the assert is to mark that this particular piece of code breaks once the operation supports tensor semantics. I personally can live with removing it but I would say it is a safety net and it also helps to understand the code. Comparing an output tensor otherwise may seem strange otherwise...
My question was to validate my understanding: "in the current state of this op, this check could be added to the verifier and nothing would break"?
You're saying "The verification already checks the input and output operands are memrefs", but it isn't obvious to a reader (like River here) that this implies the same thing as this assert, hence my clarifying question.