Greetings everyone. I am trying to make a description for an operation to create a constant with a literal value and a corresponding type for it - as to this moment only Integer and Float values are to be supported, so I decided to use AnyAttrOf-parameter for the type and have no arguments for the operation (the decision is based on the example of MLIR LLVM-dialect.
def Const : DFCIR_DialectType<"DFCIRConst", "const", [ConstantLike]> {
let parameters = (ins AnyAttrOf<[Builtin_IntegerAttr, Builtin_FloatAttr]>:$value);
let assemblyFormat = "`<` $value `>`";
}
def ConstOp : DFCIR_Op<"const_op"> {
let assemblyFormat = " type($res)";
let results = (outs Const:$res);
}
The problem appears when I am trying to use mlir-rblgen - something causes an error and a stack dump to appear:
The problem persists if I am using AnyAttr as well. Could anyone please give me a hint of how to deal with it? The error says to post an issue on GitHub, but I am almost sure I just did something wrong and it’s not MLIR’s fault. Thank you very much in advance.
Looks like a bug in TableGen, but without a debug build with symbols it hard to say where it comes from. Can you try providing a reproducer in the test dialect?
I need to be able to reproduce myself locally on my computer the problem. The most convenient is to produce the same op and same type in the TestDialect in MLIR and post a patch showing the issue.
I don’t reproduce at HEAD, but you haven’t mentioned which revision you tried?
$ bin/mlir-tblgen --gen-typedef-decls /tmp/check.td -I ../mlir/include
Included from /tmp/check.td:1:
Included from ../mlir/include/mlir/IR/OpBase.td:18:
Included from ../mlir/include/mlir/IR/Interfaces.td:16:
Included from ../mlir/include/mlir/IR/AttrTypeBase.td:17:
../mlir/include/mlir/IR/CommonAttrConstraints.td:171:7: error: Missing `cppType` field in Attribute/Type parameter: anonymous_387
class AnyAttrOf<list<Attr> allowedAttrs, string summary = "",
^
Basically it is complaining that you’re using a constraint as parameter of a Type here (instead of an operation argument)
I am afraid I wasn’t using a particular release, but a main branch build at this commit. If the problem was about using a constraint as a type parameter, is there a way to parametrize a type with an arbitrary attribute? If we are speaking about a constant-defining operation, we need to be able to somehow create a constant of an arbitrary type and without the mentioned above functionality we would have to make a parameterless type, but the operation will have the parameters of the type.
It’s unusual to encode the constant value in the type system (in general we “type erase” this by returning the same “scalar type” for constant and variable).
That said it opens also some interesting properties, wonder what kind of tradeoff we’re getting into here.
Does it mean that by ensuring this “type erasure”-like pattern we achieve simpler type specification, yet forcing ourselves to refer to the operation where the value of said type was returned in case we need to verify its semantics at some point? If that’s the case, then I believe I understand how to work with something like that better.
The type in both cases is just i32. The users of the SSA value don’t need to know that it was produced from a constant or from the result of other operations.