Add ability to be able to group ops together in documentation generation. This
results in section of ops grouped together under one summary & description.
This doesn't do anything special for the groups beyond nesting yet.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/include/mlir/IR/OpBase.td | ||
---|---|---|
2529–2534 | Did you consider adding a "group" or "docGroup" property to each op instead / in addition to this? // One-line human-readable description of what the op does. string summary = ""; // Additional, longer human-readable description of what the op does. string description = ""; // Optional group label used by documentation generation. string group = ""; That way, each op could say which group it belongs to, rather than need to keep a separate list of which ops belong to which group. | |
mlir/test/mlir-tblgen/gen-dialect-doc.td | ||
21–25 | Does this support multiple groups? If so, can you include multiple groups in this test? |
mlir/include/mlir/IR/OpBase.td | ||
---|---|---|
2531 | Please add some comments on what the fields are (self explanatory but it always helps) |
mlir/include/mlir/IR/OpBase.td | ||
---|---|---|
2529–2534 | I didn't want to mix the op definitions with a documentation mechanism. E.g., the group they are in is purely "cosmetic" at this point. I could see a benefit though in that then one could use tablegen classes to create groups (if you already have a binary base class). I'll think a bit. |
mlir/include/mlir/IR/OpBase.td | ||
---|---|---|
2529–2534 | Isn't the "description" similarly "cosmetic"? Concrete example: //===----------------------------------------------------------------------===// // TOSA Spec Section 2.4 // Operator Class: Elementwise unary/binary/ternary operators. // Operator Subclass: Elementwise binary ops. //===----------------------------------------------------------------------===// //===----------------------------------------------------------------------===// // Operator: add //===----------------------------------------------------------------------===// def Tosa_AddOp : Tosa_ElemWiseBinaryOp<"add", [Commutative]> { let summary = "Elementwise addition operator"; let description = [{ Elementwise addition of input1 and input2. Axis of size 1 will be broadcast, as necessary. }]; Should a group be added like this: def : OpDocGroup { let summary = "Elementwise binary ops"; let description = "Elementwise binary ops (TOSA Spec Section 2.4)."; let ops = [Tosa_AddOp, Tosa_ArithmeticRightShiftOp, Tosa_BitwiseAndOp, ...]; } Or like this? def Tosa_AddOp : Tosa_ElemWiseBinaryOp<"add", [Commutative]> { let summary = "Elementwise addition operator"; let description = [{ Elementwise addition of input1 and input2. Axis of size 1 will be broadcast, as necessary. }]; let group = "elementwise_binary"; Maybe a combination of the two? (One for a label, another for the information backing that label) |
mlir/include/mlir/IR/OpBase.td | ||
---|---|---|
2529–2534 | Good question, I see the description as useful locally when one reads the file, while the group is more rendered side. I think the two step is easier for folks to use though [I'll update post meetings :)] |
Patched and tested downstream in IREE with a few groups in one of our larger dialects. Looks good! I'll need to tune our table of contents (TOC) depth level for each page, but that's to be expected.
mlir/test/mlir-tblgen/gen-dialect-doc.td | ||
---|---|---|
33–36 | nit: in the spirit of https://llvm.org/docs/CodingStandards.html#namespace-indentation , I'd suggest putting a comment where the group is closed. It's less important in this small test, but larger files with 100s of lines between the group open and group close would benefit from that style being used. |
I was actually thinking about that and how to handle ops not in a group is tricky. I could for example make all operand sub headings all be at the same depth, that would give (at max depth 2)
test.A Goup test.B test.C
rather than (depth 1)
test.A Group test.C
or (if one did as here and didnt' nest even ungrouped ops)
test.A Operands Group test.b test.C Operands
I could make it such that if you use any op grouping all ops get grouped and there is like a remainder section (I didn't like this one). Biasedly I looked at where this was used similarly and found that current approach covers it.
mlir/tools/mlir-tblgen/OpDocGen.cpp | ||
---|---|---|
371 |
I'd expect groups with one item to be nested as usual. I have a practical example (with some screenshots) here: https://github.com/openxla/iree/pull/14194#discussion_r1239127215 I might explicitly put ungrouped ops into an "other" group, since it's ambiguous whether the common infrastructure should do that on its own, as you point out. |
Please add some comments on what the fields are (self explanatory but it always helps)