MLIR type syntax


Following the reference syntax of types in MLIR it would seem that complex type definitions such as memref<?x memref<?xf32>> are possible.

Experience shows that such type definitions are rejected by mlir-opt. Is there a rationale on why? Is this maybe a current limitation of the TF dialect, or is it a permanent limit? And what is the exact limit - is it forbidden to have a ShapedType as base type in a memref?

The same stands for tensor types.

My question is not completely intellectual - allowing such constructs would allow a simpler expression of recurrent algorithms that take variable-sized sequences of inputs. And thus possibly avoid in many cases the manipulation of opaque references of type !tf.variant.

Best regards,

As with languages, the fact that something is correct syntactically doesn’t imply that it is also correct semantically. I don’t know what would be the semantics of memref<!llvm.void>, for example. Memref supports a restricted set of built-in types as elements because we know how to handle these types in memory, which isn’t the case for an arbitrary type. I have ideas on how to make this extensible, but haven’t had time so far to write a proposal.

Well, it depends on the language. C would not reject a syntactically correct program that passes basic type checking, and OCaML would follow clear-cut type-checking rules. Still, I got your point.