[Mlir-commits] [mlir] [mlir] [memref] Compile-time memref.alloc Scheduling/Merging optimization (PR #95882)

llvmlistbot at llvm.org llvmlistbot at llvm.org
Thu Jun 20 23:17:09 PDT 2024


Menooker wrote:

> Before actually reviewing this - can we get a high-level overview of the design here?

I have a rendered document at https://github.com/Menooker/llvm-project/blob/MemoryPlanning/mlir/docs/MemrefMergeAlloc.md

The [section](https://github.com/Menooker/llvm-project/blob/MemoryPlanning/mlir/docs/MemrefMergeAlloc.md#merge-alloc-pass) introduces the target of the pass.

The [section](https://github.com/Menooker/llvm-project/blob/MemoryPlanning/mlir/docs/MemrefMergeAlloc.md#general-framework-for-implementation-of-merge-alloc) introduces the 4 basic steps of the optimizaion:

```
Collect the memory alias via BufferViewFlowAnalysis
Collect the memory lifetime traces
Schedule the buffers by an allocation algorithm to compute the offsets of each allocations
Rewrite the IR to replace allocations with views of merged buffers
```

Detail implementations are discussed [here](https://github.com/Menooker/llvm-project/blob/MemoryPlanning/mlir/docs/MemrefMergeAlloc.md#tick-based-implementation-for-merge-alloc)

> Also, as a quick question: how usable would this be if I only want to handle one particular memory space (say `#gpu.address_space<workgroup>`)

The current design only supports default address space. I used to plan to support multiple addr-spaces in some later fix-ups. But I am considering supporting it in this initial PR.

https://github.com/llvm/llvm-project/pull/95882


More information about the Mlir-commits mailing list