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

[Fabian Mora]

fabianmcg wrote:

> > Yes, they can be parsed in the context of an op, but there's still no method to do it outside an op.
> 
> I believe this is what I wrote?
> 
> > To use a similar example, yes, we can parse attrtype parameters with a FieldParser, but there's no generic parameter parsing logic because it doesn't make sense, they are meant to be parsed inside attrs or types, not as a standalone units.
> 
> Again, I acknowledged this, but what's your point? I don't quite connect this to the overall design question here.

That answer was mostly to say: yes, there's some printing and parsing for props, but not in a state to do the same trick we do with attrs with no good binding support where we parse them in python as an alternative. The parameter comment was to say, that in the same way it wouldn't make sense to expose the `FieldParser` logic to python, it wouldn't make sense to expose it for properties (in their current form).


> > Attrs are a mechanism to specify constant information, the specific semantics are defined by the attr itself [1],
> 
> I'm confused: I don't see a "meaning" here? If we're talking semantics and look at for example an IntegerAttr and you're saying that the semantics is that it models an integer, then I don't quite see how different it is from a `int` property...
> 
> > An EnumAttr has semantics and syntax outside an operation
> 
> What is the semantics outside of an operation that an EnumAttr has that an EnumProp does not?

IMO, the semantics and meaning of an attr are owned by the attr, while for a prop they are owned (let's say jointly) by the op. An attribute is a standalone unit, that can be parsed, printe, stored generically and have interfaces. A prop only makes sense in the context of the op, and it's mostly a C++ impl detail to store it.
Now, if we were to extend props in a way that they become a standalone unit, then I'd drop my arguments.

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