In code generators, one can automate the translation of typed ArrayAttrs if element attribute translators are already implemented. However, the type of the element attribute is lost at the construction of TypedArrayAttrBase. With this change one can inspect the element type and generate the translation logic automatically, which will reduce the code repetition.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Unit tests: pass. 62196 tests passed, 0 failed and 815 were skipped.
clang-tidy: pass.
clang-format: pass.
Build artifacts: diff.json, clang-tidy.txt, clang-format.patch, CMakeCache.txt, console-log.txt, test-results.xml
Pre-merge checks is in beta. Report issue. Please join beta or enable it for your project.
Can you give me a pointer as to how to test this? I searched for a similar test for baseAttr in the repo but couldn't find one. This is something that you would use while inspecting TableGen records. Should the test be a cpp file under mlir/test/lib/TableGen that inspects a td file?
Sorry for the late reply! Existing tests for TableGen are testing TableGen backends in tree. What @abeakkas has here is a field for an out-of-tree TableGen backend so I'm not sure that there is a good approach except for just dumping the record without invoking any backend and check the field is as expected.
mlir/test/mlir-tblgen/op-attribute.td | ||
---|---|---|
250 ↗ | (On Diff #243233) | Can we have RECORD-LABEL to match SomeTypedArrayAttr before this? Otherwise it's too broad a range to match against. |