This revision performs a lot of different cleanups on operation documentation to ensure that they are consistent:
- using mlir code blocks
- removing custom syntax for operations that have it auto-generated
rriddle on Mar 24 2020, 2:59 PM.Authored by
A lot of this is auto-generated using https://github.com/llvm/llvm-project/blob/master/mlir/utils/spirv/gen_spirv_dialect.py . Would be better to update that so that it doesnt get reverted when we use the script to regenerate the .td files. Let me know if you want one of us to take that up (should be a simple change.
Actually, strike what I said earlier. The script uses the existing text for an op.
But can you just update these two lines of the script to match what you have here. https://github.com/llvm/llvm-project/blob/92744f624783d92a07db25bc76e181b879f17e5b/mlir/utils/spirv/gen_spirv_dialect.py#L677 - #L678
Also I think (@antiagainst can confirm), the ### Custom assembly format is used as a demarcartor by the generator script. I tried to find cases above where it is removed.
The first part of description (before ### Custom assembly form) is automatically populated from the SPIR-V spec by the gen_spirv_dialect.py tool. The part after ### Custom assembly form is manually added. So ### Custom assembly form is the anchor at the moment to split. To remove it means we need rethink how the documentation is done. (The Example ... mlir part is fine as Mahesh pointed out.) Can I ask what do we want to achieve here? Will you automatically generate the custom assembly form's doc some way?
The overall goal is to bring some uniformity to the dialect documentation, and clean it up. The assembly form weirdness comes from the fact that we already generate a section for the syntax when the operation uses the assemblyFormat field, which leads to some redundancy: e.g. https://mlir.llvm.org/docs/Dialects/SPIRVDialect/#spv_address_of-spirvaddressofop