Reasoning about memref mutability

We are looking into things like a use-range analysis and buffer reuse that could, in your example, remove the memref.copy operation. We do not have all the required interfaces in place, yet, to make this happen.

With that work, you would not need the in/out parameter but can simply have two in parameters and (eventually) an output shape, which for now has to be a tensor due to limitations in the modelling. I think that longer term vision should put @mehdi_amini concern’s to rest. Mutable tensors indeed would be funky but that is not what is really happening here.

What we would still need is some annotation that tells us that a buffer that is passed to a function is owned by that function. inplaceable serves this purpose in the linalg bufferization. We have not explored cross function lifetime, because in all our settings, that is a dynamic property.


That is great news Stephan! Yes, anything that removes the copy and changes the O(N) code back into O(nnz) would make me extremely happy!

Which is why I used “experiment” very deliberately in the first post here in the context of inplaceable annotations. I do not expect this to remain in the form I am using it now, but it has enabled me to already experiment with the kind of code that would be generated once the proper interfaces are in place (and also makes it easier to show current and desired code in discussions like this).

Thanks for constructively addressing my concerns on this!

Thank you for many attention to this memref mutability issue.
Through this discussion, I can get better understanding about bufferization and relevant restrictions on memref dialect.

It seems like these restrictions are planned to be seperated from memref dialect to better represent partial bufferization steps.
I also think that’s a good idea in that it can ensure this imutability only applies to that step. (not for all memref dialect).

I just saw the fix to the documentation and I still find it quite twisted in how it reads. It does also directly contradict the statement above “Clones the data in the input view into an implicitly defined output view.”. Is this op misnamed? From the description, it’s more like a freeze_and_clone_read_only?

I agree, if anything the documentation update was meant as a band aid to at least make it correct. The output is implicitly defined as opposed to explicitly allocated and copied into. It can be defined as an alias.

I did not have the time to move this into its own dialect but I will get that done. That will take a little longer, though.