The attribute grammar includes an optional trailing colon type, so for attributes without a constant buildable type this will generally lead to unexpected and undesired behavior. Given that, it's better to just error out on these cases.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Awesome, thank you River! Is this also introducing TypedStrAttr as a new way to specify an attribute that cannot have a ": type" production in the parser? Is there a way to spell that?
mlir/include/mlir/Dialect/Affine/IR/AffineOpsBase.td | ||
---|---|---|
23 | Shouldn't this be I64? The affine map's results / inputs are Index type, but when the affine map is a constant, that constant is an int64 (and not of index bit width). |
Not exactly, TypedStrAttr is intended to be a way to specify a StrAttr with a non-None type; given that NoneType is the overwhelmingly common case.
You can already use the valueType field, used here, to specify that an attribute has a static type and to print/parser without it. For example, if you have an I32Attr today it won't print/parse
the type because we can statically construct an I32 type from the builder. This revision uses that knowledge to check if the attribute parses the type or not.
mlir/include/mlir/Dialect/Affine/IR/AffineOpsBase.td | ||
---|---|---|
23 | I'm basing this off of the type of the MLIR attribute, which is always Index. |
mlir/include/mlir/Dialect/Affine/IR/AffineOpsBase.td | ||
---|---|---|
23 | I see - looks like I completed missed what valueType here meant. |
Shouldn't this be I64? The affine map's results / inputs are Index type, but when the affine map is a constant, that constant is an int64 (and not of index bit width).