Basically the interface would have methods such as getAddOpName that query the proper attribute is part of the op.
The verifier would ensure that these are present.
The tablegen definition of the op would need to specify this attribute (could be a unique dictionary attr).
Note that you want to avoid putting all attributes on everything so the interface should specify which subset of ops it expects (e.g. NamedAddMulOpInterface or NamedOpInterface<“add_op”, “mul_op”> where add_op/mul_op could well be “arith.max” / “arith.addi”).
You can builder.create(OperationState) and explicitly pass the name in OperationState.
This is how local ops that aren’t registered with a dialect can be created locally.
Yes, and you prob want a “default” that can be elided to avoid increasing verbosity in the common case.
Parsing and printing may be more involved here but it would be a good thing to better separate the auto-generated named ops form the load bearing generic.
I was just thinking that if you want to configure a much more advanced region than a simple fma + a few unary ops, the general case will likely be:
func @some_impl(%a: !my_fancy_type) {
%b = another_op(%a, %a)
%c = call @some_other_function_(b) : (!my_fancy_type) -> (!my_fancy_type)
return %b: !my_fancy_type
}
linalg.my_fancy_op impl="some_impl fun" (%O: memref<?x!my_fancy_type>)
whenever you need to lower to loops you can just inline @some_impl where it is needed.
This would be the more general setup for which we don’t wand special attrs name.