31 Bufferization
Bufferization changes value-like tensor computations into operations on mutable memory buffers when a later representation requires explicit storage. It is one of MLIR’s most consequential representation changes because it introduces aliasing, allocation, and lifetime concerns that tensor IR intentionally hides.
31.1 Tensor And Buffer Semantics Differ
A tensor value behaves like an immutable aggregate. Updating an element produces a new tensor value, and SSA use-def chains describe dataflow. A memref denotes storage that may be read or written by multiple operations. Two memrefs may alias the same memory even when their SSA values differ.
Bufferization cannot therefore be modeled as a type spelling substitution. It must decide whether an output can reuse an input buffer, when a copy is needed, which operation owns an allocation, and whether a read observes a prior write through an alias.
31.2 In-Place Or Out-Of-Place
An in-place bufferization reuses storage when analysis proves it is safe. An out-of-place conversion allocates or copies a new buffer to preserve tensor value semantics. Reusing a buffer too aggressively changes observable results when an earlier tensor value is still used. Copying everything is safe but often destroys performance and hides optimization opportunities.
Bufferization analyses use operand/result relationships, aliases, reads, writes, and ownership conventions. Dialect operations participate through bufferization interfaces or models. An operation without an accurate model is a boundary: the pipeline must conservatively copy, keep it in tensor form, or provide a correct custom conversion.
31.3 Ownership And Deallocation
After bufferization, allocation and lifetime are explicit. A pipeline needs a policy for stack allocation, heap allocation, escape analysis, deallocation, and interoperation with calls. The correct policy depends on the target runtime. A memref that escapes a function cannot be deallocated like a local temporary.