summaryrefslogtreecommitdiffstats
path: root/llvm/docs/Remarks.rst
Commit message (Collapse)AuthorAgeFilesLines
* [Remarks] Remove references to ELF supportFrancis Visoiu Mistrih2019-10-281-1/+0
| | | | | | There is no ELF support at the moment. Remove all the references to the `.remarks` section.
* [Remarks] Emit the remarks section by default for certain formatsFrancis Visoiu Mistrih2019-10-281-3/+7
| | | | | | | | | Emit a remarks section by default for the following formats: * bitstream * yaml-strtab while still providing -remarks-section=<bool> to override the defaults.
* Reland: [Remarks] Add an LLVM-bitstream-based remark serializerFrancis Visoiu Mistrih2019-07-311-0/+245
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a new serializer, using a binary format based on the LLVM bitstream format. This format provides a way to serialize the remarks in two modes: 1) Separate mode: the metadata is separate from the remark entries. 2) Standalone mode: the metadata and the remark entries are in the same file. The format contains: * a meta block: container version, container type, string table, external file path, remark version * a remark block: type, remark name, pass name, function name, debug file, debug line, debug column, hotness, arguments (key, value, debug file, debug line, debug column) A string table is required for this format, which will be dumped in the meta block to be consumed before parsing the remark blocks. On clang itself, we noticed a size reduction of 13.4x compared to YAML, and a compile-time reduction of between 1.7% and 3.5% on CTMark. Differential Revision: https://reviews.llvm.org/D63466 Original llvm-svn: 367364 Revert llvm-svn: 367370 llvm-svn: 367372
* Revert "[Remarks] Add an LLVM-bitstream-based remark serializer"Francis Visoiu Mistrih2019-07-311-245/+0
| | | | | | | | This reverts commit r367364. Breaks some bots: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-gn/builds/3161/steps/annotate/logs/stdio llvm-svn: 367370
* [Remarks] Add an LLVM-bitstream-based remark serializerFrancis Visoiu Mistrih2019-07-301-0/+245
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a new serializer, using a binary format based on the LLVM bitstream format. This format provides a way to serialize the remarks in two modes: 1) Separate mode: the metadata is separate from the remark entries. 2) Standalone mode: the metadata and the remark entries are in the same file. The format contains: * a meta block: container version, container type, string table, external file path, remark version * a remark block: type, remark name, pass name, function name, debug file, debug line, debug column, hotness, arguments (key, value, debug file, debug line, debug column) A string table is required for this format, which will be dumped in the meta block to be consumed before parsing the remark blocks. On clang itself, we noticed a size reduction of 13.4x compared to YAML, and a compile-time reduction of between 1.7% and 3.5% on CTMark. Differential Revision: https://reviews.llvm.org/D63466 llvm-svn: 367364
* [Remarks] Add two serialization modes for remarks: separate and standaloneFrancis Visoiu Mistrih2019-07-301-0/+20
| | | | | | | | | | The default mode is separate, where the metadata is serialized separately from the remarks. Another mode is the standalone mode, where the metadata is serialized before the remarks, on the same stream. llvm-svn: 367328
* Reland: [Remarks] Support parsing remark metadata in the YAML remark parserFrancis Visoiu Mistrih2019-07-261-9/+24
| | | | | | | | | | | | | | | | This adds support to the yaml remark parser to be able to parse remarks directly from the metadata. This supports parsing separate metadata and following the external file with the associated metadata, and also a standalone file containing metadata + remarks all together. Original llvm-svn: 367148 Revert llvm-svn: 367151 This has a fix for gcc builds. llvm-svn: 367155
* Revert "[Remarks] Support parsing remark metadata in the YAML remark parser"Francis Visoiu Mistrih2019-07-261-24/+9
| | | | | | | | | This reverts r367148. Seems to fail on http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fuzzer/builds/27768. llvm-svn: 367151
* [Remarks] Support parsing remark metadata in the YAML remark parserFrancis Visoiu Mistrih2019-07-261-9/+24
| | | | | | | | | | | This adds support to the yaml remark parser to be able to parse remarks directly from the metadata. This supports parsing separate metadata and following the external file with the associated metadata, and also a standalone file containing metadata + remarks all together. llvm-svn: 367148
* [Remarks] Introduce a new format: yaml-strtabFrancis Visoiu Mistrih2019-07-231-0/+29
| | | | | | | | | This exposes better support to use a string table with a format through an actual new remark::Format, called yaml-strtab. This can now be used with -fsave-optimization-record=yaml-strtab. llvm-svn: 366849
* [Remarks] Simplify and refactor the RemarkParser interfaceFrancis Visoiu Mistrih2019-07-161-0/+1
| | | | | | | | | | | | | | | | | | | | Before, everything was based on some kind of type erased parser implementation which container a lot of boilerplate code when multiple formats were to be supported. This simplifies it by: * the remark now owns its arguments * *always* returning an error from the implementation side * working around the way the YAML parser reports errors: catch them through callbacks and re-insert them in a proper llvm::Error * add a CParser wrapper that is used when implementing the C API to avoid cluttering the C++ API with useless state * LLVMRemarkParserGetNext now returns an object that needs to be released to avoid leaking resources * add a new API to dispose of a remark entry: LLVMRemarkEntryDispose llvm-svn: 366217
* [docs][Remarks] Add documentation for remarks in LLVMFrancis Visoiu Mistrih2019-07-091-0/+305
This adds documentation that describes remarks in LLVM. It aims at explaining what remarks are, how to enable them, and what users can do with the different modes. It lists all the available flags in LLVM (excluding clang), and describes the expected YAML structure as well as the tools that support the YAML format today. Differential Revision: https://reviews.llvm.org/D64355 llvm-svn: 365578
OpenPOWER on IntegriCloud