[Mlir-commits] [mlir] add IntegerLikeTypeInterface to enable out-of-tree uses of built-in attributes that otherwise force integer types (PR #137061)

[Jeremy Kun]

j2kun wrote:

I am happy to add a "DenseElementsAttrContainable" interface, but it seems a bit clunky to support that for all the types supported in a DenseElementsAttr (float, complex, and integer). Would it make more sense to have an interface for each supported element class? "DenseIntElementsAttrCompatible", "DenseFloatElementsAttrCompatible," etc?

Supporting DenseElementsAttrs via an interface also doesn't cover the case of parsing a single integer literal. Would a separate interface for that work? Maybe, "IntegerLiteralParseable"?

Am I to infer from this discussion that the MLIR design prefers more interfaces that cover less behavior each, even if some of the interfaces overlap in what they do? My feeling was to have one interface that provides the underlying need (storage width for integers) and then any place in the codebase that requires knowledge of the underlying storage width can use it. That feels like a more solid design to me, but maybe this discussion has been had before many times and I'm not aware of how it was resolved.

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