llvm-project/llvm/lib/Remarks/CMakeLists.txt

add_llvm_component_library(LLVMRemarks
  BitstreamRemarkParser.cpp
  BitstreamRemarkSerializer.cpp
  Remark.cpp
  RemarkFormat.cpp
  RemarkLinker.cpp
  RemarkParser.cpp
  RemarkSerializer.cpp
  RemarkStreamer.cpp
  RemarkStringTable.cpp
  YAMLRemarkParser.cpp
  YAMLRemarkSerializer.cpp
)
[cmake] Explicitly mark libraries defined in lib/ as "Component Libraries" Summary: Most libraries are defined in the lib/ directory but there are also a few libraries defined in tools/ e.g. libLLVM, libLTO. I'm defining "Component Libraries" as libraries defined in lib/ that may be included in libLLVM.so. Explicitly marking the libraries in lib/ as component libraries allows us to remove some fragile checks that attempt to differentiate between lib/ libraries and tools/ libraires: 1. In tools/llvm-shlib, because llvm_map_components_to_libnames(LIB_NAMES "all") returned a list of all libraries defined in the whole project, there was custom code needed to filter out libraries defined in tools/, none of which should be included in libLLVM.so. This code assumed that any library defined as static was from lib/ and everything else should be excluded. With this change, llvm_map_components_to_libnames(LIB_NAMES, "all") only returns libraries that have been added to the LLVM_COMPONENT_LIBS global cmake property, so this custom filtering logic can be removed. Doing this also fixes the build with BUILD_SHARED_LIBS=ON and LLVM_BUILD_LLVM_DYLIB=ON. 2. There was some code in llvm_add_library that assumed that libraries defined in lib/ would not have LLVM_LINK_COMPONENTS or ARG_LINK_COMPONENTS set. This is only true because libraries defined lib lib/ use LLVMBuild.txt and don't set these values. This code has been fixed now to check if the library has been explicitly marked as a component library, which should now make it easier to remove LLVMBuild at some point in the future. I have tested this patch on Windows, MacOS and Linux with release builds and the following combinations of CMake options: - "" (No options) - -DLLVM_BUILD_LLVM_DYLIB=ON - -DLLVM_LINK_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_BUILD_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_LINK_LLVM_DYLIB=ON Reviewers: beanz, smeenai, compnerd, phosek Reviewed By: beanz Subscribers: wuzish, jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, mgorny, mehdi_amini, sbc100, jgravelle-google, hiraditya, aheejin, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, steven_wu, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, PkmX, jocewei, jsji, dang, Jim, lenary, s.egerton, pzheng, sameer.abuasal, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70179 2019-11-14 13:39:58 +08:00			`add_llvm_component_library(LLVMRemarks`
[Remarks] Add parser for bitstream remarks The bitstream remark serializer landed in r367372. This adds a bitstream remark parser that parser bitstream remark files to llvm::remarks::Remark objects through the RemarkParser interface. A few interesting things to point out: * There are parsing helpers to parse the different types of blocks * The main parsing helper allows us to parse remark metadata and open an external file containing the encoded remarks * This adds a dependency from the Remarks library to the BitstreamReader library * The testing strategy is to create a remark entry through YAML, parse it, serialize it to bitstream, parse that back and compare the objects. * There are close to no tests for malformed bitstream remarks, due to the lack of textual format for the bitstream format. * This adds a new C API for parsing bitstream remarks: LLVMRemarkParserCreateBitstream. * This bumps the REMARKS_API_VERSION to 1. Differential Revision: https://reviews.llvm.org/D67134 llvm-svn: 371429 2019-09-10 01:43:50 +08:00			`BitstreamRemarkParser.cpp`
Reland: [Remarks] Add an LLVM-bitstream-based remark serializer 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 2019-07-31 08:13:51 +08:00			`BitstreamRemarkSerializer.cpp`
Reland "[Remarks] Add a new Remark / RemarkParser abstraction" This adds a Remark class that allows us to share code when working with remarks. The C API has been updated to reflect this. Instead of the parser generating C structs, it's now using a C++ object that is used through opaque pointers in C. This gives us much more flexibility on what changes we can make to the internal state of the object and interacts much better with scenarios where the library is used through dlopen. * C API updates: * move from C structs to opaque pointers and functions * the remark type is now an enum instead of a string * unit tests updates: * use mostly the C++ API * keep one test for the C API * rename to YAMLRemarksParsingTest * a typo was fixed: AnalysisFPCompute -> AnalysisFPCommute. * a new error message was added: "expected a remark tag." * llvm-opt-report has been updated to use the C++ parser instead of the C API Differential Revision: https://reviews.llvm.org/D59049 Original llvm-svn: 356491 llvm-svn: 356519 2019-03-20 05:11:07 +08:00			`Remark.cpp`
[Remarks][NFC] Combine ParserFormat and SerializerFormat It's useless to have both. llvm-svn: 366216 2019-07-16 23:24:59 +08:00			`RemarkFormat.cpp`
[Remarks] Add support for linking remarks Remarks are usually emitted per-TU, and for generating a standalone remark file that can be shipped with the linked binary we need some kind of tool to merge everything together. The remarks::RemarkLinker class takes care of this and: * Deduplicates remarks * Filters remarks with no debug location * Merges string tables from all the entries As an output, it provides an iterator range that can be used to serialize the remarks to a file. Differential Revision: https://reviews.llvm.org/D69141 2019-09-11 06:48:55 +08:00			`RemarkLinker.cpp`
[OptRemarks] Make OptRemarks more generic: rename OptRemarks to Remarks Getting rid of the name "optimization remarks" for anything that involves handling remarks on the client side. It's safer to do this now, before we get stuck with that name in all the APIs and public interfaces we decide to export to users in the future. This renames llvm/tools/opt-remarks to llvm/tools/remarks-shlib, and now generates `libRemarks.dylib` instead of `libOptRemarks.dylib`. Differential Revision: https://reviews.llvm.org/D58535 llvm-svn: 355439 2019-03-06 04:45:17 +08:00			`RemarkParser.cpp`
[Remarks] Simplify the creation of remark serializers Introduce two new functions to create a serializer, and add support for more combinations to the YAMLStrTabSerializer. llvm-svn: 366919 2019-07-25 00:36:35 +08:00			`RemarkSerializer.cpp`
[Remarks] Extend the RemarkStreamer to support other emitters This extends the RemarkStreamer to allow for other emitters (e.g. frontends, SIL, etc.) to emit remarks through a common interface. See changes in llvm/docs/Remarks.rst for motivation and design choices. Differential Revision: https://reviews.llvm.org/D73676 2019-10-29 05:53:31 +08:00			`RemarkStreamer.cpp`
[Remarks] Add string deduplication using a string table * Add support for uniquing strings in the remark streamer and emitting the string table in the remarks section. * Add parsing support for the string table in the RemarkParser. From this remark: ``` --- !Missed Pass: inline Name: NoDefinition DebugLoc: { File: 'test-suite/SingleSource/UnitTests/2002-04-17-PrintfChar.c', Line: 7, Column: 3 } Function: printArgsNoRet Args: - Callee: printf - String: ' will not be inlined into ' - Caller: printArgsNoRet DebugLoc: { File: 'test-suite/SingleSource/UnitTests/2002-04-17-PrintfChar.c', Line: 6, Column: 0 } - String: ' because its definition is unavailable' ... ``` to: ``` --- !Missed Pass: 0 Name: 1 DebugLoc: { File: 3, Line: 7, Column: 3 } Function: 2 Args: - Callee: 4 - String: 5 - Caller: 2 DebugLoc: { File: 3, Line: 6, Column: 0 } - String: 6 ... ``` And the string table in the .remarks/__remarks section containing: ``` inline\0NoDefinition\0printArgsNoRet\0 test-suite/SingleSource/UnitTests/2002-04-17-PrintfChar.c\0printf\0 will not be inlined into \0 because its definition is unavailable\0 ``` This is mostly supposed to be used for testing purposes, but it gives us a 2x reduction in the remark size, and is an incremental change for the updates to the remarks file format. Differential Revision: https://reviews.llvm.org/D60227 llvm-svn: 359050 2019-04-24 08:06:24 +08:00			`RemarkStringTable.cpp`
Reland "[Remarks] Add a new Remark / RemarkParser abstraction" This adds a Remark class that allows us to share code when working with remarks. The C API has been updated to reflect this. Instead of the parser generating C structs, it's now using a C++ object that is used through opaque pointers in C. This gives us much more flexibility on what changes we can make to the internal state of the object and interacts much better with scenarios where the library is used through dlopen. * C API updates: * move from C structs to opaque pointers and functions * the remark type is now an enum instead of a string * unit tests updates: * use mostly the C++ API * keep one test for the C API * rename to YAMLRemarksParsingTest * a typo was fixed: AnalysisFPCompute -> AnalysisFPCommute. * a new error message was added: "expected a remark tag." * llvm-opt-report has been updated to use the C++ parser instead of the C API Differential Revision: https://reviews.llvm.org/D59049 Original llvm-svn: 356491 llvm-svn: 356519 2019-03-20 05:11:07 +08:00			`YAMLRemarkParser.cpp`
[Remarks][NFC] Move the serialization to lib/Remarks Separate the remark serialization to YAML from the LLVM Diagnostics. This adds a new serialization abstraction: remarks::Serializer. It's completely independent from lib/IR and it provides an easy way to replace YAML by providing a new remarks::Serializer. Differential Revision: https://reviews.llvm.org/D62632 llvm-svn: 362160 2019-05-31 05:45:59 +08:00			`YAMLRemarkSerializer.cpp`
[OptRemarks] Make OptRemarks more generic: rename OptRemarks to Remarks Getting rid of the name "optimization remarks" for anything that involves handling remarks on the client side. It's safer to do this now, before we get stuck with that name in all the APIs and public interfaces we decide to export to users in the future. This renames llvm/tools/opt-remarks to llvm/tools/remarks-shlib, and now generates `libRemarks.dylib` instead of `libOptRemarks.dylib`. Differential Revision: https://reviews.llvm.org/D58535 llvm-svn: 355439 2019-03-06 04:45:17 +08:00			`)`