[Mlir-commits] [mlir] [mlir-python] Emit only dialect `EnumAttr` registrations. (PR #117918)

[Maksim Levental]

makslevental wrote:

> lthough the example you showed, shows an attribute from LinalgTransformEnums.td as in builtin dialect so not sure about the heuristic

which one? `MatchInterfaceEnum` and `TransposeMatmulInput`? these are both `I32EnumAttr`s so they are in `builtin`? [LinalgTransformEnums.td](https://github.com/llvm/llvm-project/blob/main/mlir/include/mlir/Dialect/Linalg/TransformOps/LinalgTransformEnums.td)

> And I was thinking if one could do something more automatic by associating ops with the nearest Dialect definition in include path. But that heuristic could be too magical.

yea definitely too magical.

> WDYT about making it explicit via file acted on as the other?

In general I think automatically inferring via file location is just as magical/error-prone. As you commented, GPU would now have attributes in the "wrong" place but according to what semantic? Only the semantic introduced by such a change (prior they were just conventions). 

My change also introduces a new semantic but the semantic "every dialect gets dialect attributes generated/emitted automatically" and `builtin` continues to be treated special (requires hand-written `register_attribute_builder` calls) is more conservative than the alternative.

But I'll just say, since I'm no longer andactive user of these bindings (I'm just pitching in to help @kuhar), I won't stand in the way of something that unblocks _some_ fix. If you think pinning to file location is fine and it works for you guys then we can land that instead (it'll work for us too).



https://github.com/llvm/llvm-project/pull/117918