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

[Matthias Springer]

matthias-springer wrote:

> For example, in HEIR we have a mod_arith dialect which is effectively an integer storage type with an added modulus.

fyi, we have a similar use case internally. There is a special integer type with a modulo type parameter. Initially, we wanted to reuse `arith`/... ops with this type because we get foldings/canonicalizations for free. One approach that we looked into was adding an `IntegerTypeInterface`. In the end, we did not explore that path further because ops like `arith.addi` enforce that all operands/results must have the same type, but we needed an op that works with different modulus values.

> The parser fails even for regular integer attributes, because Parser::parseDecOrHexAttr constrains the type provided to an integer type ([in the integer branch](https://github.com/llvm/llvm-project/blob/30fec128e8cc515392521628771510b347411c28/mlir/lib/AsmParser/AttributeParser.cpp#L428))

Do you actually want to reuse this function? It performs checks such as "parsed literal is not negative if the integer type is unsigned". You probably want to add your own checks to ensure that the parsed literal is divisible by the modulus value of your integer type.

> The parser fails for dense elements attrs, e.g., mod_arith.constant dense<0> : tensor<8x!mod_arith.int<127 : i32>> because the parser hard-constrains a DenseElementsAttr to have integer or integer-like (again, in the integer branch of the parser).

Where is that check? I was looking at `parseDenseElementsAttr`, but couldn't find it there.

> The DenseElementsAttr itself similarly requires an integer-like type to be attached to the attribute, or else you can't do things like iterate over the values in it.

Does `denseAttr.getValues<Attribute>()` not work?


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