In general, I don’t really have any strong reasoning on “adding MemRefTypeInterface to a pointer” situation (honestly, I would be appalled if that happened), this is a valid point. My only comment would be: since both Tensor/MemRefType attach ShapedTypeInterface, the tensor/memref-wannabe has to also implement interface methods of that (e.g. getShape() / getElementType()) - due to transitivity - so such a type really has to be special?
If we want bufferization specifically to work with non-builtin types, we should generalize bufferization.
Yes. In which case, bufferization has to introduce its own “tensor” and “memref” concepts on top of pretty much ShapedType. I would assume these concepts would look pretty much like the base classes from builtins.
Thinking a bit more generically, what bufferization seems to need (and, to be fair, MLIR in general?) is a “shaped type with a tag” where that tag says “tensor” / “memref”. At least within bufferization logic this is the bare minimum change I can think of. Since MLIR already kind of has it (through the aforementioned base classes), it seems reasonable to just extend them to larger use.
Also, I vaguely remember sparse tensor discussion where the general premise was something along the lines of “it would be really cool to have sparse tensor as its own thing”. I believe having “tensor type interface” of sorts aids this as well? (As mentioned in the proposal, I believe that dealing with “tensors” without knowing what they are is a powerful concept). I guess this also boils down to what MLIR tries to be: so far I interpret it as a general framework and to me it seems to miss an abstraction around tensors / memrefs.
It is perfectly normal for RFCs to stay up for O(weeks) and for other contributors to answer them at their preferred pace. We are not on-call here.
Sorry!