[Mlir-commits] [mlir] port fixes from local llvm (PR #78484)

[ian Bearman]

manbearian wrote:

Thanks for taking a look. My thoughts below:
 
> 1. Since the encoding attribute is quite generic i.e., it can be used for storing any information, I wonder if only converting it to the `MemorySpace` attribute is restrictive? For ex: In my use-case, I am storing layout information that may be represented with a `LayoutMap` in MemRef.

The changes i'm making don't actually convert encoding attributes. Rather, the new API allows an implementer to set the memory-space of converted types. One can use the encoding to set memory-space, e.g. to provide a mapping from encoding to memory-space, but this it is not limited to this.

Two ways to maybe get what you're looking for:
- another new API could be added to set the layout of newly created memrefs. Similar to `getMemorySpace` one could add the additional API `getLayout`. One pitfall here is allocation: i'm not sure one can allocate a buffer with a non-identity layout.
- use the encoding attribute and then run a pass to fold the attribute into the layoutmap when it is possible after bufferization is complete.

> 2. The Bufferization pass results in the creation of `bufferization.to_memref`  Ops. These Ops have verifiers that fail when trying to bufferize a tensor with encoding attribute. Namely, `getTensorTypeFromMemRefType` defined in `mlir/include/mlir/Dialect/MemRef/IR/MemRef.h`, used to verify if the new MemRef Type created by `bufferization.to_memref`  is equivalent to the tensor type, does not check the encoding attribute and fails if an encoding attribute is present on the tensor type.

This sounds familiar, but i don't recall exactly if i've seen this. The code i'm pushing here is used internally for Microsoft's MLIR-based AI Complier, so: i've either fixed this locally and need to push a fix upstream; it's fixed in this PR; or i haven't hit this yet. I'll keep my eye out to try and catch if it's the first one.


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