MLIR: lib/Dialect/Bufferization/Transforms/OneShotAnalysis.cpp File Reference (original) (raw)

Go to the source code of this file.

◆ DEBUG_TYPE

#define DEBUG_TYPE "one-shot-analysis"

◆ annotateConflict()

◆ annotateNonWritableTensor()

◆ annotateOpsWithAliasSets()

◆ annotateOpsWithBufferizationMarkers()

◆ areNonConflictingSubsets()

◆ bottomUpFromTerminatorsHeuristic()

◆ bufferizableInPlaceAnalysisImpl()

◆ canUseOpDominance()

◆ canUseOpDominanceDueToBlocks()

Return true if op dominance can be used to rule out a read-after-write conflicts based on the ordering of ops.

Returns false if op dominance cannot be used to due block-based loops within a region.

Refer to the canUseOpDominanceDueToRegions documentation for details on how op domiance is used during RaW conflict detection.

On a high-level, there is a potential RaW in a program if there exists a possible program execution such that there is a sequence of DEF, followed by WRITE, followed by READ. Each additional DEF resets the sequence.

Op dominance cannot be used if there is a path from block(READ) to block(WRITE) and a path from block(WRITE) to block(READ). block(DEF) should not appear on that path.

Definition at line 401 of file OneShotAnalysis.cpp.

References mlir::Operation::getBlock(), mlir::detail::IROperandBase::getOwner(), mlir::Operation::getParentRegion(), and mlir::Block::isReachable().

Referenced by canUseOpDominance().

◆ canUseOpDominanceDueToRegions()

Return true if op dominance can be used to rule out a read-after-write conflicts based on the ordering of ops.

Returns false if op dominance cannot be used to due region-based loops.

Generalized op dominance can often be used to rule out potential conflicts due to "read happens before write". E.g., the following IR is not a RaW conflict because the read happens before the write.

Example 1: %0 = ... : tensor<?xf32> // DEF "reading_op"(%0) : tensor<?xf32> // READ %1 = "writing_op"(%0) : tensor<?xf32> -> tensor<?xf32> // WRITE

This is no longer true inside loops (or repetitive regions). In such cases, there may not be a meaningful happensBefore relationship because ops could be executed multiple times. E.g.:

Example 2: %0 = ... : tensor<?xf32> // DEF scf.for ... { "reading_op"(%0) : tensor<?xf32> // READ %1 = "writing_op"(%0) : tensor<?xf32> -> tensor<?xf32> // WRITE ... }

In the above example, reading_op happens before writing_op according to op dominance. However, both ops may happen multiple times; in particular, the second execution of reading_op happens after the first execution of writing_op. This is problematic because the tensor %0 they operate on (i.e., the "definition") is defined outside of the loop.

On a high-level, there is a potential RaW in a program if there exists a possible program execution such that there is a sequence of DEF, followed by WRITE, followed by READ. Each additional DEF resets the sequence.

E.g.: No conflict: DEF, WRITE, DEF, READ Potential conflict: DEF, READ, WRITE, READ, WRITE

Example 1 has no conflict: DEF, READ, WRITE Example 2 has a potential conflict: DEF, (READ, WRITE)* Example 3: scf.for ... { %0 = ... : tensor<?xf32> "reading_op"(%0) : tensor<?xf32> %1 = "writing_op"(%0) : tensor<?xf32> -> tensor<?xf32> ... } This has no conflict: (DEF, READ, WRITE)*

Example 4: %0 = ... : tensor<?xf32> scf.for ... { scf.for ... { "reading_op"(%0) } %1 = "writing_op"(%0) } This has a potential conflict: DEF, ((READ)*, WRITE)*

Example 5: %0 = ... : tensor<?xf32> scf.for ... { %1 = "writing_op"(%0) } scf.for ... { "reading_op"(%0) } This has a potential conflict: DEF, WRITE*, READ*

The following rules are used to rule out RaW conflicts via ordering of ops:

1. If the closest enclosing repetitive region of DEF is a proper ancestor of a repetitive region that enclosing both READ and WRITE, we cannot rule out RaW conflict due to the ordering of ops.
2. Otherwise: There are no loops that interfere with our analysis; for analysis purposes, we can assume that there are no loops/repetitive regions. I.e., we can rule out a RaW conflict if READ happensBefore WRITE or WRITE happensBefore DEF. (Checked in hasReadAfterWriteInterference.)

Definition at line 355 of file OneShotAnalysis.cpp.

References mlir::detail::IROperandBase::getOwner(), mlir::Region::getParentOp(), mlir::Operation::isAncestor(), and options.

Referenced by canUseOpDominance().

◆ checkPreBufferizationAssumptions()

Perform various checks on the input IR to see if it contains IR constructs that are unsupported by One-Shot Bufferize.

Definition at line 1174 of file OneShotAnalysis.cpp.

References mlir::WalkResult::advance(), mlir::Operation::emitOpError(), mlir::Operation::getOpOperands(), mlir::bufferization::OneShotAnalysisState::getOptions(), mlir::Operation::getRegions(), mlir::WalkResult::interrupt(), mlir::bufferization::OneShotAnalysisState::isInPlace(), options, success(), mlir::Operation::walk(), mlir::WalkResult::wasInterrupted(), wouldCreateReadAfterWriteInterference(), and wouldCreateWriteToNonWritableBuffer().

Referenced by mlir::bufferization::analyzeOp().

◆ equivalenceAnalysis() [1/2]

◆ equivalenceAnalysis() [2/2]

◆ getAliasingInplaceWrites()

◆ getAliasingReads()

◆ happensBefore()

◆ hasEquivalentValueInReverseUseDefChain()

Return 'true' if a tensor that is equivalent to other can be found in the reverse use-def chain of start.

Note: If an OpOperand bufferizes out of place along that use-def chain, the two tensors may not materialize as equivalent buffers (but separate allocations).

Note: This function also requires that the two tensors have equivalent indexing. I.e., the tensor types do not change along the use-def chain, apart from static <-> dynamic dim casts.

Definition at line 470 of file OneShotAnalysis.cpp.

References mlir::config.

Referenced by hasReadAfterWriteInterference().

◆ hasReadAfterWriteInterference()

Given sets of uses and writes, return true if there is a RaW conflict under the assumption that all given reads/writes alias the same buffer and that all given writes bufferize inplace.

A conflict is: According to SSA use-def chains, a read R is supposed to read the result of a definition W1. But because of bufferization decisions, R actually reads another definition W2.

Definition at line 590 of file OneShotAnalysis.cpp.

References annotateConflict(), areNonConflictingSubsets(), canUseOpDominance(), mlir::Block::findAncestorOpInBlock(), mlir::bufferization::OneShotAnalysisState::findDefinitionsCached(), mlir::bufferization::OneShotAnalysisState::getOptions(), happensBefore(), hasEquivalentValueInReverseUseDefChain(), and options.

Referenced by wouldCreateReadAfterWriteInterference().

◆ isaTensor()

◆ isInplaceMemoryWrite()

◆ matchesInsertDestination()

◆ setInPlaceOpOperand()

◆ wouldCreateReadAfterWriteInterference()

Return true if bufferizing operand inplace would create a conflict.

A read R and a write W of the same alias set is a conflict if inplace bufferization of W changes the value read by R to a value different from the one that would be expected by tracing back R's origin through SSA use-def chains. A conflict can only be introduced by a new alias and/or an inplace bufferization decision.

Example: %0 = tensor.extract_slice t[...][...][1, 1] {inplace?} %1 = vector.transfer_write v1, t {inplace} : vector<5xf32>, tensor<?xf32> e = tensor.extract_slice %1 %2 = vector.transfer_write v2, %0 {inplace} : vector<6xf32>, tensor<?xf32> %3 = vector.transfer_read e, cst : tensor<?xf32>, vector<7xf32>

In the above example, the two TransferWriteOps have already been decided to bufferize inplace. Bufferizing the ExtractSliceOp inplace would create a conflict because:

• According to SSA use-def chains, we expect to read the result of %1.
• However, adding an alias {%0, t} would mean that the second TransferWriteOp overwrites the result of the first one. Therefore, the TransferReadOp would no longer be reading the result of %1.

If checkConsistencyOnly is true, this function checks if there is a read-after-write conflict without bufferizing operand inplace. This would indicate a problem with the current inplace bufferization decisions.

Note: If checkConsistencyOnly, this function may be called with a null OpResult. In that case, only the consistency of bufferization decisions involving aliases of the given OpOperand are checked.

Definition at line 881 of file OneShotAnalysis.cpp.

References mlir::IROperand< DerivedT, IRValueT >::get(), getAliasingInplaceWrites(), getAliasingReads(), and hasReadAfterWriteInterference().

Referenced by bufferizableInPlaceAnalysisImpl(), and checkPreBufferizationAssumptions().

◆ wouldCreateWriteToNonWritableBuffer()

◆ kBbArgAliasSetAttrName

◆ kInPlaceOperandsAttrName

◆ kOpResultAliasSetAttrName