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

[Mehdi Amini]

joker-eph wrote:

> IntegerAttr, which similarly only needs the bit width to determine the APInt storage size, and is similarly hard-coded to have integer type in the attribute as well as the parser.

But consumers of the IntegerAttr expect right now that it only encodes an integer: they will consume it as such and manipulate it as such (in folder code for example): I don't quite see how making it extensible would work here? 

> Would it make sense to have an IntLikeElementsAttr upstream that supports more type compatibility but also uses integer storage?

Would that be an interface or a concrete attribute? If a concrete one, would it replace (or compete with) DenseIntOrFPElementsAttr for integers?
At this point I lost track if it's possible to allow other "int types" for DenseIntOrFPElementsAttr instead?

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