[RFC] Linalg on Tensors Update and Comprehensive Bufferization RFC

[nicolasvasilache]

@mehdi_amini

Yes, you’re touching on it, but this isn’t going deeply enough for me to understand. You also briefly mention an interface, but that seems to indicate to me that there is an opportunity to not make anything Linalg specific here and instead decoupling this through an interface?
I’d really like to see this fleshed out and landed in a decoupled manner from Linalg op.

Let’s scratch a little deeper then and see what would be potential requirements and specific non-goals.

In the description of the steps above the mechanisms described as well as the current implementation are indeed independent. In the current implementation, LinalgOp appears in 3 places:

1. getTiedOpResult impl: this is the place that switches on op types to determine for a given op whether its semantics allow an operand and a result to reuse the same buffer. This is an op-specific behavior that could be implemented with an interface.
2. detectLinalgToTerminator impl looks for a specific destructive update pattern involving a Linalg op. Other patterns do not involve Linalg ops. We could imagine some hook mechanism to decouple the specification of such patterns from specific ops. I don’t think this is load bearing and anything beyond an implementation detail.
3. convertLinalgOp bufferization impl which is the op-specific bufferization: that’s the cost of doing business and not specific to Linalg op.

The more relevant load-bearing aspects of this bufferization address the issues I raised previously in the post on Properly using bufferization related passes; mainly that it is a single pass that performs an analysis followed by a simple Module.walk and does not leak abstractions across pass boundaries.

In light of these explanations, I believe points 1. and 2. fall into the category of implementation details.