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

[River Riddle]

River707 wrote:

> > the location and name of the interface implied that, as did some parts of the original PR description.
> 
> Right, this is kind of what I was aiming at.
> 
> > Would it be acceptable if we scoped the feature to "builtin attributes can use non-builtin types, when those types implement the appropriate interface?"
> 
> This seems consistent with what we did for the Vector type recently: #133455
> 
> You mention "builtin attributes", are you looking at more than `DenseElementsAttr` right now? Note also the existence of the `ElementsAttrInterface`, which went in a different direction but with similar end goal somehow. Instead of making `DenseElementsAttr` extensible with custom types, we instead allowed folks to use their own replacement for `DenseElementsAttr`.

Yeah, DenseElementsAttr supporting "all of the cases" turned out to be a major pain and a mistake (though DenseElementsAttr isn't the attribute, it's DenseIntOrFPElementsAttr and DenseStringElementsAttr). That's a big part of why the extensibility there is pushed via ElementsAttr, it allows users to do whatever they want with the storage mechanisms. There is a lot of special casing code sprinkled all over those attributes that makes assumptions around int == IntegerType and fp == FloatType. Interface-ifying FloatType was an easier transition because there were always a number of specific float types. For IntegerType there has always only been "IntegerType", we didn't want to have multiple types in that hierarchy (which also goes back to why signedness is part of the type and not multiple different types).



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