We would like to remove the tight coupling of the
BufferDeallocation pass to the
linalg dialects. Currently, this pass creates
linalg.copy operations in certain cases to create temporary copies and free allocated buffers.
In order to remove this coupling, we could think about several different ways to achieve this purpose:
- Extend the notion of “allocation resources” to provide the opportunity in order to create associated copy and free operations.
- Provide an abstract interface that is passed to the
BufferDeallocationpass constructor in order to create the appropriate operations for each case.
- An additional option, that we have not been aware of
There are different pros and cons related to these approaches.
Extended Allocation Resources
The advantage of this approach would be that each individually specialized allocation resource can provide its unique methods to create copies and free operations without touching the actual operations it is associated with. This would have the additional benefit of creating other
std.alloc like operations in different dialects that can essentially inherit the same copy and free behavior. Furthermore, this solution would be accessible from the whole ”MLIR universe”.
One major question that arises would be how to handle cases in which we must create temporary copies from multiple allocation resources:
%0 = "my_alloc"(...) : memref<...> br ^bb1(%0 : ...) ... %1 = "other_alloc"(...) : memref<...> br ^bb1(%1 : ...) ... ^bb1 (%2 : memref<...>) ... // %2 could now point to memory locations provided by two different alloc // operations that might leverage different allocation resources
However, as far as I remember, @River707 pointed out that these resources are just a temporary solution and might be replaced in the future…
This possibility would avoid any interference with allocation resources or operations in the MLIR project. Instead, the
BufferDeallocation pass can then create the appropriate operations for each case. This would also cover the example above: In such a case, a specific function could be invoked on this particularly designed interface that specifies which operation(s) should be generated. The downside of this approach is the obvious limitation to the
BufferDeallocation pass that would block us from reusing these features in other passes/parts of the MLIR project.
What do you think about these options? Are there alternative solutions?