[Mlir-commits] [mlir] [mlir] NamedAttribute utility generator (PR #75118)

[Mehdi Amini]

joker-eph wrote:

> No, that is true but most usages are StringLiteral except when copying from a NamedAttribute. It is complicated since it is context dependent. Do you have any suggestion?

What I have been doing in the past is defining these as StringAttr on the dialect instance instead.

> Perhaps that is a bridge too far. We have scenarios where an inherent attribute on an op is copied to the enclosing func or module and should then be dialect-qualified. I could live with a DialectNamedAttrDef and an NamedAttrDef (unqualified).

The whole concept of using an "AttrDef" here is still unclear to me right now to begin with.
I'm also not sure I'm making a direct connection between your usage of inherent attribute and a propagation as a discardable one.

In general with properties we should be relying more and more on Interfaces to access informations about an operation instead of relying on "name lookup": in this model the name of the inherent attribute shouldn't matter, and shouldn't even be exposed (it is an implementation detail of the storage).



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