[all-commits] [llvm/llvm-project] 83ca1f: [mlir][bufferization] Add `BufferOriginAnalysis`

Matthias Springer via All-commits all-commits at lists.llvm.org
Sun Mar 24 18:55:52 PDT 2024


  Branch: refs/heads/users/matthias-springer/buffer_origin_analysis
  Home:   https://github.com/llvm/llvm-project
  Commit: 83ca1fb504ec2f4dcd7d80a21070c05ec2ec773e
      https://github.com/llvm/llvm-project/commit/83ca1fb504ec2f4dcd7d80a21070c05ec2ec773e
  Author: Matthias Springer <springerm at google.com>
  Date:   2024-03-25 (Mon, 25 Mar 2024)

  Changed paths:
    M mlir/include/mlir/Dialect/Bufferization/IR/BufferizationOps.td
    M mlir/include/mlir/Dialect/Bufferization/Transforms/BufferViewFlowAnalysis.h
    M mlir/lib/Dialect/Bufferization/Transforms/BufferDeallocationSimplification.cpp
    M mlir/lib/Dialect/Bufferization/Transforms/BufferViewFlowAnalysis.cpp
    M mlir/test/Dialect/Bufferization/Transforms/buffer-deallocation-simplification.mlir

  Log Message:
  -----------
  [mlir][bufferization] Add `BufferOriginAnalysis`

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 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. (TODO: Add test case.) Such IR patterns are generated by the sparse compiler.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications


More information about the All-commits mailing list