Simple questions on constraints of MLIR's design

Hello everyone. Right now I am struggling with a couple of issues I ran into while trying to design a MLIR dialect for Dataflow Engines and I am afraid I couldn’t find specific information in neither the provided documentation nor examples. I would be very grateful if you could help me.

  1. Recently I found out that it is possible to parametrize a type with another type like this:
let parameters = (ins "Type":$stream_type);

and it would be quite helpful to me, but when I tried to do the same with an operation

def InputOp : DFCIR_Op<"input"> {
	let arguments = (ins

I couldn’t get over the following error error: undefined type for argument #0 regarding the operation described above. Am I correct to assume it is by design that you cannot parametrize an operation with a type or do I have other issues in my code? I used the same inclusion directives as I had used in the types-file, primarily

include "mlir/IR/"
include "mlir/IR/"
include "mlir/IR/"
include "mlir/IR/"

and yet the error remains.

  1. If we are trying do describe an operation with a number of arguments: attributes and operands, neither of which can be omitted and attributes represent data which you can’t/shouldn’t express with an SSA-variable with a type (a name for a data stream, for example), isn’t it possible to define an assembly format relatively close to one that of, let’s say, a C++ function code, where string literals don’t have to be wrapped in a dictionary like we have to in MLIR?

Speaking more specific, I am trying to make the following pattern
let assemblyFormat = "`<` $type `>` `(` $name (`,` $ctrl^)? `)`"; where $name is the only attribute and if we forget the problem №1 with parametrizing ops with types and don’t use the optional $ctrl-operand, I wanted to achieve the following syntax for the operation input in dfcir dialect:


As you can see, the string literal aaaaa isn’t incased in attributes dictionary, and because of that I keep running into the following error
error: `attr-dict` directive not found in custom assembly format . Is it necessary to use a number of directives like attr-dict in custom assembly formats or is there a workaround for it?

As I have mentioned before, I would be really glad if you could help me because right now I cannot progress further with my work, so thanks in advance!

Yeah I don’t think you can use "Type" directly as an argument to an op. Instead, you can use TypeAttr.

Ok, but it still seems kind of strange that in one case Type can be an attribute or an operand and in another case only an attribute - I must be missing something. I will look into TypeAttr, thank you. And speaking of the second issue, I believe there is truly a number of “must-have” directives, even though the assembly form in some cases could look better without them (yeah, it might be subjective, I understand).

Type can’t be “an attribute or an operand”, when you define a type it can be one of the “parameters” of this type. That’s all inside the type-definition world, which has nothing to do with the op-definitions.
Operations arguments are attributes/properties or Values, there is no notion of a “type” here. The “TypeAttr” exists mainly for the purpose of “adapting” the Type domain to be attached to operations.

You must include attr-dict, because there is no way to prevent adding extra discardable attribute to an operation and these must have a place to be printed (and parsed).
That’s not preventing you from having the syntax example you provided, just add the attr-dict directive afterward.

Ok, I got the picture. Thank you very much!