[nfc][docs]Generalize header description and ascii art for indexed profiles #83507
Conversation
minglotus-6
commented
Mar 1, 2024
minglotus-6
commented
- Add pointers to code for source of truth.
- Move necessary details from doc to code.
- Add pointers to code for source of truth. - Move necessary details from doc to code.
|
I think the doc is easier to maintain by removing boilerplates. Otherwise it's painful to update ascii art graph with templated content. Planned to submit this change before #83309. |
llvm/docs/InstrProfileFormat.rst
Outdated
| | | +-----------------------+ O | ||
| | +->| Binary Ids | A | ||
| | Byte Offset | A | ||
| +------ | of section 2 | D |
There was a problem hiding this comment.
why starting the number from 2?
There was a problem hiding this comment.
Profile summary is regarded as the first payload section and it doesn't need an offset.
I revised the graph to use section A B ... Z, and added a note to mention profile summary.
llvm/docs/InstrProfileFormat.rst
Outdated
| ``HashType`` | ||
| The hashing scheme for on-disk hash table keys. Only MD5 hashing is used as of | ||
| writing. | ||
| The `Header struct`_ should be the source of truth. Field names and comments |
There was a problem hiding this comment.
Probably document the sections are A, B, C, and D, and their order is defined in Header struct.
There was a problem hiding this comment.
Incorporate the section names in the graph above and reworded the paragraph slightly.
For indexed profiles, the byte offset is relative to the start of profile memory buffer. Thereby the field order in the struct definition doesn't need to be the same as the order of payloads in the profile (e.g., if we need it sometime in the future).
minglotus-6
changed the title
|
Bump. |
