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

donald chen llvmlistbot at llvm.org
Tue Jun 25 08:41:31 PDT 2024


cxy-1993 wrote:

This patch is a nice beginning. And there are some top level questions should be answered before any further review:
1. I don't think encoding op with tik is a reasonable approach. Should we use data flow framework analysis to obtain more accurate liveness? Merge in this way is not acceptable to me.
2. Alloc is a dynamic behavior. The alloc in the loop re-applies for a new space each time it is executed, but this static memory planning treats the alloc memory as a one-time application, which is wrong and dangerous. Should we reconsider whether our starting point is correct?
3. Liveness of memory does not always correspond to op. For example, in some asynchronous architectures(such as async load and mma in GPU), different hardware components can issue and commit instructions concurrently. Should we model this behavior?
4. In multi-threaded execution environments (such as GPU), the liveness of shared memory cannot be bound to op either. It may involve handling memory fences/barriers to construct the correct liveness. Should we also model this scenario?

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


More information about the Mlir-commits mailing list