I’m starting to hit up against the limitations of the default builder that we ODS generate for the python dialect wrappers, and before spending any time thinking about it, I wanted to see if we had a design in mind already for it.
I feel like to get any real generality, we are just going to need to go all in and implement a C+±side generic builder that can match the signatures properly. I could see this being exposed to the Python generated code as something like:
@_ods_cext.def_opview_builder( _ods_cext.def_builder( ... need to figure out what goes here ... ), _ods_cext.def_builder( ... need to figure out what goes here ... ) ) @_ods_cext.register_operation(_Dialect) class BatchMatmulOp(_ods_ir.OpView): OPERATION_NAME = "linalg.batch_matmul"
add_opview_builder decorator would install an appropriate init method on the class and could also augment the documentation systematically.
Right now, we generate some relatively… twisty… python code for materializing the default builder. I feel like in order to have a hope of efficiency (relatively – this is still python) and error messages, we just need to implement this facility natively. That way we can build a pretty efficient pattern matcher that uses normal C++ types and avoid a lot of dynamic dispatch (paying the cost at dialect load time instead of per op instantiation). Also, I just really don’t want to be tablegen generating a non trivial search of a builder pattern match tree for Python
Also, I was hoping that someone had an opinion about how we should map region based op builders. In Python, I’ve found it moderately nice to just instantiate the regions on the op and then access them by a symbolic name to keep building (i.e. versus the C++ style of passing a callback).
For reference, I have generated the python wrappers for a handful of core dialects: MLIR Python Dialect Bindings · GitHub