PSA: Python bindings (`EnumAttr`s)

MLIR
1

Hot off the presses: ⚙ D157934 [mlir][python bindings] generate all the enums

A couple or three things about this diff/PR/changeset:

  1. Upstream dialects now have automatic bindings generated for *EnumAttrs (including I32EnumAttrs, I32BitEnumAttrs, and plain EnumAttrs, i.e., dialect enum attributes). See here, here, and here for examples.
  2. If you were already using register_attribute_builder to register an attribute builder for some such enum and you would like to continue to use it, you can by passing replace=True to the decorator (see here). Note that you need to do this after the upstream one is registered (i.e., after the dialect module is imported); otherwise you will get a RuntimeError about duplicate registration (when the upstream attribute builder tries to replace yours).
  3. Downstream dialects can sign up for the same automatic generation using the GEN_ENUM_BINDINGS param to declare_mlir_dialect_python_bindings (see here). Note this will generate bindings for all EnumAttrs defined in your trampoline *Ops.td including definitions in imports/includes. If your *Ops.td has upstream dialect tds included then you might end up generating duplicated bindings and if so they will collide with existing bindings (same aforementioned RuntimeError). Currently the workaround is to either refactor your *Ops.td or use the soon-to-be-deprecated GEN_ENUM_BINDINGS_TD_FILE param (see this discussion on the phabricator review).

Thanks @rkayaith and @stellaraccident for the review.

Any questions/comments/concerns can be directed directly at me.

Thank you for flying with us and we hope you have a nice day.

1 Like
LLVM Weekly - #504, August 28th 2023
2

Wow thanks so much for this @makslevental. This will make things a lot nicer and cleaner!

1 Like