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

[llvmlistbot at llvm.org]

Menooker wrote:

Thanks for your comments and review, @cxy-1993 !

> 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.

Could you elaborate why you think ticks does not work? Any examples to show that tick-based impl cannot handle while data flow framework analysis can?

We need a "total ordering" (not sure if the term is correctly used here) of all allocations' first-access and last-access in a linear timeline to drive the "static memory planner", which is malloc-free-event based. Tick is a simple and effective approach to achieve this.

> 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?

Explained in another reply. Hope that makes sense to you.

> 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?
> 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?

Good point... That's why I made a "framework" instead of a simple pass for `merge-alloc`. The components of the default implementation can be overridden by developers to support different devices. Any suggestions on modeling of these behaviors?





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