Simple questions on constraints of MLIR's design

MLIR
1

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
		"Type":$type,
...

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/OpBase.td"
include "mlir/IR/DialectBase.td"
include "mlir/IR/AttrTypeBase.td"
include "mlir/IR/BuiltinAttributes.td"

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:

dfcir.input<dfcir.int(32)>("aaaaa")

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!

2

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

3

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).

4

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.

5

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