[Mlir-commits] [mlir] add IntegerLikeTypeInterface to enable out-of-tree uses of built-in attributes that otherwise force integer types (PR #137061)
Jeremy Kun
llvmlistbot at llvm.org
Thu Apr 24 08:55:57 PDT 2025
j2kun wrote:
> Initially, we wanted to reuse `arith`/... ops with this type because we get foldings/canonicalizations for free.
We don't want or hope to reuse arith dialect infrastructure, as the semantics are different even just for folding rules. We only want to reuse the auto-generated parsers and printers for literals, and the attribute storage for folding.
> > Parser::parseDecOrHexAttr
> 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.
I don't directly use this function, it is what `parseAttribute` calls when encountering an integer literal (cf. https://github.com/llvm/llvm-project/blob/2ca071b1decf006a31385c75478b57013964e49a/mlir/lib/AsmParser/AttributeParser.cpp#L122). Note that here and below, I'm simply using `assemblyFormat = "attr-dict $value"` and using the auto-generated parser and printer.
> > 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.
It is inside `buildAttributeAPInt`, which all of the parse methods use, and which this PR relaxes to allow non-integer types. In particular, tensor literal parsing calls it from https://github.com/llvm/llvm-project/blob/2ca071b1decf006a31385c75478b57013964e49a/mlir/lib/AsmParser/AttributeParser.cpp#L655 and DenseArray from https://github.com/llvm/llvm-project/blob/2ca071b1decf006a31385c75478b57013964e49a/mlir/lib/AsmParser/AttributeParser.cpp#L886
> > 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?
The default printer generated for the above `assemblyFormat` calls `getValues<APInt>` (I believe this is the more specific overload resolved during template resolution, but I am not a template wizard), which enforces the type constraint at print time.
https://github.com/llvm/llvm-project/pull/137061
More information about the Mlir-commits
mailing list