I used ref as an example. i have also used type but it gives an error. i was looking to see how i could change to take an enum directly instead of a StrAttr.
The best way to get help is to give us a minimal reproducible example that results in exactly the error you are trying to resolve. Otherwise we will be looking at wrong errors because of incorrect simplifications or assumptions.
You cannot use type() with attributes, only with operands or results.
Maybe if you explain what you are trying to achieve by “using enumattr as a type”, we will find a better way.
For the assembly format, I would think you could do: attr-dict($type ,$id):(type($id)) → type($out) ; you don’t need to separate the type from the attribute here.
The builder is a separate question: the declarative assembly is unrelated.
You should look at the generated code to see the list of builders that are present, there should be a variant that operates on the enum.
I checked the codebase, we don’t generate builders for these because they are stored as StringAttr.
The generated builders would hide some non-trivial cost (stringify + context lookup for the StringAttr).
You can easily add these to your op though
let builders = [
OpBuilder<(ins "ExampleEnum":$type, "Value":$id),
[{
auto typeAttr = StringAttr::get($_builder.getContext(), stringifyEnum($type));
build($_builder, $_state, typeAttr, id);
}]>];
(I haven’t tried to build it, you may have to adjust)
The generated builders require a type for the result of the operation because it can’t be inferred from the arguments and it isn’t a “buildable” type (a type that does not need any argument to be built)
You have in your ODS above let results = (outs Example:$example); ; that says that:
your operation will have one result only: the verifier will fail if you create such an operation with no result or more than one. A OneResult trait will be added to the operation, which make available the C++ method Value getResult();.
The type of the result must be Example. You’re not providing the definition for Example here so I can’t say much more about it. If it was a AnyTensor we’d would check that the Type matches the predicate .isa<::mlir::TensorType>() for example, so that if you were to use something else for result it would fail the verifier.
The name of the result is example. There will be an accessor generated for it Value example();.
When you create the operation, you need to provide the type for this example result. This type must be an instance of Example. Again without knowing moe about Example, I can’t be specific. But if it was AnyTensor then you need to provide an instance of a TensorType when creating your operation.
Now if the Example type is something like a very specific type, let’s say an i32. It seems unnecessary to provide it explicitly as it is unambiguous. Such types are defined in ODS as a “BuildableType”. The generated builder would omit them from the list.
Finally, there are operations which can infer the result type from the arguments provided. For example if the operation declares the trait SameOperandsAndResultType then it will generate a builder that does not take the result type as argument and it’ll use the argument type instead.
StrEnumAttr has genSpecializedAttr property (which is off by default). If it is set to 1, the mlir-tblgen will generate extra Attribute class, which will wrap conversion from string and the enum class. Something like that:
enum class MyEnum { ... };
class MyEnumAttr : public StringAttr {
using ValueType = MyEnum;
static MyEnumAttr get(MLIRContext* ctx, MyEnum val);
MyEnum getValue() const;
static bool classof(Attribute attr);
};
This will also switch all StrEnumAttr users to the MyEnumAttr and MyEnum directly. MyEnumAttr will perform string <-> enum conversions internally. This feature is disabled by default, since it has performance penalty (the string <-> enum conversion).
The similar Attribute class is also generated for IntEnumAttr and it is enabled by default, since for that case there is no performance penalty (int <-> enum conversion is cheap).