MLIR type syntax

MLIR
1

Hello,

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,
Dumitru

2

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.

1 Like
3

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.