Lines Matching refs:ops
7 Bufferization in MLIR is the process of converting ops with `tensor` semantics
8 to ops with `memref` semantics. MLIR provides an infrastructure that bufferizes
10 bufferizes all ops that implement the
40 implementations not only provide the rewrite logic from tensor ops to memref
41 ops, but also helper methods for One-Shot Bufferize's analysis to query
44 * **Extensible** via an op interface: All ops that implement
68 typically as one of the last steps right before lowering memref ops. Many
78 rewrites tensor ops into memref ops.
104 To simplify this problem, One-Shot Bufferize was designed for ops that are in
105 *destination-passing style*. For every tensor result, such ops have a tensor
123 Tensor ops that are not in destination-passing style always bufferize to a
169 ops, e.g.:
194 that performs an analysis and bufferizes all ops with tensor semantics that
205 `allow-unknown-ops`. In that case, One-Shot Bufferize inserts
206 `to_memref`/`to_tensor` ops around the bufferization boundary. These ops are
208 analysis can currently not analyze these ops, so input IR with such ops may fail
212 One-Shot Bufferize can be configured to bufferize only ops from a set of
216 generates `to_tensor`/`to_memref` ops which One-Shot Bufferize cannot analyze.
305 One-Shot Bufferize bufferizes ops from top to bottom. This works well when all
306 ops are bufferizable. However, when encountering a non-bufferizable tensor with
307 `allow-unknown-ops`, One-Shot Bufferize must insert `to_memref` ops at the
316 When bufferizing the above IR, One-Shot Bufferize inserts a `to_memref` ops with
339 Note: There are some bufferizable ops for which a percise layout map cannot be
360 Custom ops can be bufferized if they implement `BufferizableOpInterface`. Users
397 result of `arith.constant` ops are never modified.
414 `to_tensor`/`to_memref` ops at the bufferization boundary (when run with
415 `allow-unknown-ops`). They can be combined and run in sequence. However,
416 One-Shot Bufferize must run first because it cannot analyze those boundary ops.
443 `ConversionPattern`'s that dialect authors write for converting ops that operate
444 on `tensor`'s to ops that operate on `memref`'s. A set of conventions and best
450 functionality, along with people who want to extend it to cover their own ops.
476 difficult to transform due to the presence of the deallocation ops. Thus, other
486 be a pass `X-bufferize` that knows how to bufferize all the ops in that dialect.
487 By running pass `X-bufferize` for each dialect `X` in the program, all the ops
490 Partial bufferization passes create programs where only some ops have been
493 bridging between ops that have been bufferized and ops that have not yet been
499 only eliminates materializations and issues an error if any unbufferized ops
505 bufferize ops and eliminate materializations. This has a number of disadvantages
542 backend has arranged that all ops are bufferized by partial bufferizations, so
550 The contract of a partial bufferization pass is that a subset of ops (or kinds
551 of ops, customizable by a ConversionTarget) get bufferized.
626 `bufferization.to_tensor` and `bufferization.to_memref` ops, which are inserted
638 - Bufferizes ops from the `scf` dialect.
639 - This is an example of how to bufferize ops that implement
645 which is well-commented and covers how to correctly convert ops that
652 - Bufferizes `func`, `call`, and `BranchOpInterface` ops.
653 - This is an example of how to bufferize ops that have multi-block
665 `bufferization.to_tensor` / `bufferization.to_memref` materialization ops
670 the ops in the program, leaving behind only the materializations. When possible,