文件最后提交记录最后更新时间
[mlir] Fix block merging (#97697) With this PR I am trying to address: https://github.com/llvm/llvm-project/issues/63230. What changed: - While merging identical blocks, don't add a block argument if it is "identical" to another block argument. I.e., if the two block arguments refer to the same Value. The operations operands in the block will point to the argument we already inserted. This needs to happen to all the arguments we pass to the different successors of the parent block - After merged the blocks, get rid of "unnecessary" arguments. I.e., if all the predecessors pass the same block argument, there is no need to pass it as an argument. - This last simplification clashed with BufferDeallocationSimplification. The reason, I think, is that the two simplifications are clashing. I.e., BufferDeallocationSimplification contains an analysis based on the block structure. If we simplify the block structure (by merging and/or dropping block arguments) the analysis is invalid . The solution I found is to do a more prudent simplification when running that pass. **Note**: this a rework of #96871 . I ran all the integration tests (-DMLIR_INCLUDE_INTEGRATION_TESTS=ON) and they passed.1 年前
[mlir][bufferization] Fix handling of indirect function calls (#94896) This commit fixes a crash in the ownership-based buffer deallocation pass when indirectly calling a function via SSA value. Such functions must be conservatively assumed to be public. Fixes #94780.1 年前
[mlir][bufferization] Buffer deallocation: Make op preconditions stricter (#75127) The buffer deallocation pass checks the IR ("operation preconditions") to make sure that there is no IR that is unsupported. In such a case, the pass signals a failure. The pass now rejects all ops with unknown memory effects. We do not know whether such an op allocates memory or not. Therefore, the buffer deallocation pass does not know whether a deallocation op should be inserted or not. Memory effects are queried from the MemoryEffectOpInterface interface. Ops that do not implement this interface but have the RecursiveMemoryEffects trait do not have any side effects (apart from the ones that their nested ops may have). Unregistered ops are now rejected by the pass because they do not implement the MemoryEffectOpInterface and neither do we know if they have RecursiveMemoryEffects or not. All test cases that currently have unregistered ops are updated to use registered ops.2 年前
[mlir][bufferization] Never pass ownership to functions (#80655) Even when private-function-dynamic-ownership is set, ownership should never be passed to the callee. This can lead to double deallocs (#77096) or use-after-free in the caller because ownership is currently passed regardless of whether there are any further uses of the buffer in the caller or not. Note: This is consistent with the fact that ownership is never passed to nested regions. This commit fixes #77096.2 年前
[mlir][bufferization] Make buffer deallocation pipeline op type independent (#67546) The buffer deallocation pipeline now works on modules and functions. Also add extra test cases that run the buffer deallocation pipeline on modules and functions. (Test cases that insert a helper function.)2 年前
[mlir][bufferization] Make buffer deallocation pipeline op type independent (#67546) The buffer deallocation pipeline now works on modules and functions. Also add extra test cases that run the buffer deallocation pipeline on modules and functions. (Test cases that insert a helper function.)2 年前
[mlir][bufferization] Add BufferOriginAnalysis (#86461) This commit adds the BufferOriginAnalysis, which can be queried to check if two buffer SSA values originate from the same allocation. This new analysis is used in the buffer deallocation pass to fold away or simplify bufferization.dealloc ops more aggressively. The BufferOriginAnalysis is based on the BufferViewFlowAnalysis, which collects buffer SSA value "same buffer" dependencies. E.g., given IR such as: %0 = memref.alloc() %1 = memref.subview %0 %2 = memref.subview %1 The BufferViewFlowAnalysis will report the following "reverse" dependencies (resolveReverse) for %2: {%2, %1, %0}. I.e., all buffer SSA values in the reverse use-def chain that originate from the same allocation as %2. The BufferOriginAnalysis is built on top of that. It handles only simple cases at the moment and may conservatively return "unknown" around certain IR with branches, memref globals and function arguments. This analysis enables additional simplifications during -buffer-deallocation-simplification. In particular, "regular" scf.for loop nests, that yield buffers (or reallocations thereof) in the same order as they appear in the iter_args, are now handled much more efficiently. Such IR patterns are generated by the sparse compiler.2 年前
[mlir][bufferization] Ownership-based deallocation: Allow manual (de)allocs (#68648) Add a new attribute bufferization.manual_deallocation that can be attached to allocation and deallocation ops. Buffers that are allocated with this attribute are assigned an ownership of "false". Such buffers can be deallocated manually (e.g., with memref.dealloc) if the deallocation op also has the attribute set. Previously, the ownership-based buffer deallocation pass used to reject IR with existing deallocation ops. This is no longer the case if such ops have this new attribute. This change is useful for the sparse compiler, which currently deallocates the sparse tensor buffers by itself.2 年前
[MLIR][Vector] Implement memory effect for print (#80400) Add write memory effect for the print operation. The exact memory behavior is implemented in other print-like operations such as transform::PrintOp or gpu::printf. Providing memory behavior allows using the operation in passes like buffer deallocation instead of emitting an error.2 年前
[mlir][bufferization] Buffer deallocation: Make op preconditions stricter (#75127) The buffer deallocation pass checks the IR ("operation preconditions") to make sure that there is no IR that is unsupported. In such a case, the pass signals a failure. The pass now rejects all ops with unknown memory effects. We do not know whether such an op allocates memory or not. Therefore, the buffer deallocation pass does not know whether a deallocation op should be inserted or not. Memory effects are queried from the MemoryEffectOpInterface interface. Ops that do not implement this interface but have the RecursiveMemoryEffects trait do not have any side effects (apart from the ones that their nested ops may have). Unregistered ops are now rejected by the pass because they do not implement the MemoryEffectOpInterface and neither do we know if they have RecursiveMemoryEffects or not. All test cases that currently have unregistered ops are updated to use registered ops.2 年前
Revert "[mlir][bufferization] Don't clone on unknown ownership and verify function boundary ABI (#66626)" This reverts commit aa9eb47da2e501d3505de733240eb89c9a0ea2cf. It introduced a double free in a test case. Reverting to have some time for fixing this and relanding later.2 年前
[mlir][bufferization] Add an ownership based buffer deallocation pass (#66337) Add a new Buffer Deallocation pass with the intend to replace the old one. For now it is added as a separate pass alongside in order to allow downstream users to migrate over gradually. This new pass has the goal of inserting fewer clone operations and supporting additional use-cases. Please refer to the Buffer Deallocation section in the updated Bufferization.md file for more information on how this new pass works.2 年前
Bufferization with ControlFlow Asserts (#95868) Fixed incorrect bufferization interaction with cf.assert - reordered bufferization condition checking - fixed hasNeitherAllocateNorFreeSideEffect checking bug - implemented memory interface for cf.assert --------- Co-authored-by: McCowan Zhang <mccowan.z@ssi.samsung.com>1 年前