This diff contains test code that exercises the use of Enum attributes
(integer and bit) from Python code.
The implementation in this diff manually specifies the enum values. An approach
that leverages mlir-tblgen is possible, and is a logical next step. This test
code in this diff is intended to be a proof of concept, and to act as a template
for other dialects, as well as an eventual mlir-tblgen implementation.
Python binding for Enum attributes is necessary to implement fastmath
attributes in the Arithmetic dialect. (Other dialects generate arith
operations from Python, and recent changes to Python bindings require non-None
attribute values when creating these operations.)
Just so I'm clear, you are wanting to auto generate this as a next step, right? (Which would be the first but if TableGen generated Capi we have)?
That would alleviate some of my concerns but is still a really heavy api and ask of the duplication comes with a real cost.
It occurs to me that as a class of things, we could supports common API for all enums based on some kind of opaque EnumHandle, just having one enums specific entrypoint to get the handle for a specific enums. If the common code also exposed an atoi and itoa like function, we could make the entire python implementation generic, based on reflection and exposed via an mlir.ir._DefEnum(handle_capsule).
Not that we care a ton, I guess, but pybind code really doesn't scale with either compile time or binary size to O(variants), and if reach attribute/enums just had one handle, we could reduce it to one c function and have a generated implementation that was pure c (as it would be trivial).