[Mlir-commits] [mlir] [mlir][IR] Add `getPropertyFromAttr` and `setPropertyFromAttr` methods. (PR #150060)

[Fabian Mora]

fabianmcg wrote:

> They aren't meant to be used otherwise.

Unfortunately they are also used by the C-API to create ops, see https://github.com/llvm/llvm-project/blob/main/mlir/lib/CAPI/IR/IR.cpp#L615 and https://github.com/llvm/llvm-project/blob/main/mlir/lib/IR/Operation.cpp#L41 , which is also the main mechanism to create ops in python.

But it's true those funcs are almost never used in the codebase and are there for very specific uses.

> But I wouldn't want to have to go through attributes to manipulate properties, that defeats the whole point of properties!
> We need instead a more direct way of setting them here and exposing them to binding code.

I agree on the first point, any of these calls shouldn't be used in C++ code.

But properties are an inherently C++ construct, thus interacting with them outside C++ is not trivial. Therefore, something like a tablegen solution for auto generating the bindings like in the C or python case is not longer possible, as users at the very least would have to provide code to teach the bindings how to interact with non-trivial props. Further, we would have to generate binding code for each Op concrete class.

While, we could accept this is an acceptable tradeoff, we need to realize it's a significant departure from the current model of the C and python bindings, where all custom ops interact opaquely with the Operation class (ie, we don't generate binding code for each `MyOp : public Op<...` C++ class, we interact with `MlirOperation`).

One way to not alter the current model, is to treat properties as attributes outside C++, which IMO is an acceptable tradeoff, because if one really wants to enjoy properties or MLIR to the fullest, then use C++, otherwise pay that price.

I'm open to suggestions, because there might be another path that I'm missing.

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