| Issue |
180455
|
| Summary |
`EnumAttr`s are not `EnumAttr`s
|
| Labels |
new issue
|
| Assignees |
|
| Reporter |
QuaternionsRock
|
For context, I have been trying to figure out why using [`DefaultValuedOptionalAttr`](https://github.com/llvm/llvm-project/blob/9a60b2fa0c414c4230801e792be28a92439dae8f/mlir/include/mlir/IR/CommonAttrConstraints.td#L113-L129) with my [`I32EnumAttr`](https://github.com/llvm/llvm-project/blob/769b734c020472f1f3108c912f87755174246e26/mlir/include/mlir/IR/EnumAttr.td#L339-L342) results in a compilation error even though using [`DefaultValuedAttr`](https://github.com/llvm/llvm-project/blob/9a60b2fa0c414c4230801e792be28a92439dae8f/mlir/include/mlir/IR/CommonAttrConstraints.td#L97-L111) or [`OptionalAttr`](https://github.com/llvm/llvm-project/blob/9a60b2fa0c414c4230801e792be28a92439dae8f/mlir/include/mlir/IR/CommonAttrConstraints.td#L131-L144) with it does not. I noticed that [Linalg successfully uses `DefaultValuedAttr` with its `TypeFnAttr`](https://github.com/llvm/llvm-project/blob/9a60b2fa0c414c4230801e792be28a92439dae8f/mlir/include/mlir/Dialect/Linalg/IR/LinalgStructuredOps.td#L731), and I wanted to figure out how.
Curiously, Linalg defines [`TypeFnAttr`](https://github.com/llvm/llvm-project/blob/9a60b2fa0c414c4230801e792be28a92439dae8f/mlir/include/mlir/Dialect/Linalg/IR/LinalgBase.td#L81-L83) as an [`EnumAttr`](https://github.com/llvm/llvm-project/blob/769b734c020472f1f3108c912f87755174246e26/mlir/include/mlir/IR/EnumAttr.td#L504-L563) that wraps an `I32EnumAttr` named [`TypeFn`](https://github.com/llvm/llvm-project/blob/9a60b2fa0c414c4230801e792be28a92439dae8f/mlir/include/mlir/Dialect/Linalg/IR/LinalgEnums.td#L117-L123). This causes `TypeFnAttr` to use [the `else` branch in `OperationFormat::genElementPrinter` ](https://github.com/llvm/llvm-project/blob/c53acf04433a3dea14fc3d45698919b85f9a3fca/mlir/tools/mlir-tblgen/OpFormatGen.cpp#L2579-L2581) instead of [the `if (canFormatEnumAttr(var))` branch](https://github.com/llvm/llvm-project/blob/c53acf04433a3dea14fc3d45698919b85f9a3fca/mlir/tools/mlir-tblgen/OpFormatGen.cpp#L2560-L2562) that my `I32EnumAttr` uses. (This was the indirect cause of my compilation error; `genEnumAttrPrinter` [dereferences the getter's return value if the attribute is optional](https://github.com/llvm/llvm-project/blob/0f264368e84e0c954834e3cba538c0ef09b906f7/mlir/tools/mlir-tblgen/OpFormatGen.cpp#L2293), but unlike `OptionalAttr`, `DefaultValuedOptionalAttr` does not wrap the attribute value in an `::std::optional`.)
Anyway, [`canFormatEnumAttr`](https://github.com/llvm/llvm-project/blob/c53acf04433a3dea14fc3d45698919b85f9a3fca/mlir/tools/mlir-tblgen/OpFormatGen.cpp#L431-L442) calls [`Attribute::isEnumAttr`](https://github.com/llvm/llvm-project/blob/84b5e9f8dbaf31871a1818cf8e8a93c307da12d7/mlir/lib/TableGen/Attribute.cpp#L55), which reveals something incredibly strange: `EnumAttr` is not a subclass of [`EnumAttrInfo`](https://github.com/llvm/llvm-project/blob/769b734c020472f1f3108c912f87755174246e26/mlir/include/mlir/IR/EnumAttr.td#L245-L279), therefore `EnumAttr`s are not `EnumAttr`s according to TableGen (but `IntEnumAttr`s and `BitEnumAttr`s are).
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
