[Mlir-commits] [mlir] [mlir][Tensor] Retain discardable attrs in pack(cast) folder (PR #115772)

[llvmlistbot at llvm.org]

MaheshRavishankar wrote:

> This is not true: anyone which was annotating such an op would be affected because we would preserve incorrectly an attribute, potentially leading to a crash or worse: a silent miscompile.

Here is the problem. We have two cases
1) There is an attribute that is added that gets dropped when it is being relied upon for a subsequent transformation/pass.  If we drop it then it is hard to recover this.
2) A attribute was added that is supposed to be dropped and subsequent transformation/pass relies on it being dropped. I would think this would be easier to drop the attribute prescriptively than expecting it to happen automatically.

We cant serve both cases for sure. This is really a missing feature in MLIR. An ability for an optimization to leave information for subsequent optimizations to pick up. It is fragile but this is required in many cases. This is the reason why we use it (some information is more easy to "compute" earlier in the pipeline than at the point of transformation). This is also the same reason I have seen metadata being used in LLVM. There isnt support for this feature. If MLIR had this feature it would make everyones life much easier.

> * See also Chris' message here which still seems pretty relevant: https://discourse.llvm.org/t/on-querying-an-operations-intrinsic-core-vs-external-user-defined-attributes/4498/2

On the same thread https://discourse.llvm.org/t/on-querying-an-operations-intrinsic-core-vs-external-user-defined-attributes/4498/5?u=maheshravishankar . Like I said ties back to metadata. There is no good answer here. Best way IMO is to take it on a case-by-case basis and proceed based on use case. I dont totally disagree with the comments about the pitfalls here... but I dont see why just drop the attribute is any better compared to just keep the attribute. Both are equally wrong. This goes back to, there is a missing feature here, in the absence of which people reach for the only path that allows them to do this.

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