summaryrefslogtreecommitdiffstats
path: root/llvm/unittests/XRay/CMakeLists.txt
Commit message (Collapse)AuthorAgeFilesLines
* Fix the build when LLVM_TARGETS_TO_BUILD is empty.Juergen Ributzka2018-09-191-1/+0
| | | | | | | | | | | | | | | Using LLVMTestingSupport in the LLVM_LINK_COMPONENTS breaks the build when LLVM_TARGETS_TO_BUILD is set to empty. Libraries that depend on LLVMTestingSupport need to use target_link_libraries(<target> PRIVATE LLVMTestingSupport) instead. This required change was already commited by r341899 to fix another build issue. This fixes rdar://problem/44615064. llvm-svn: 342593
* [XRay] Add missing LLVMTestingSupport target_link_librariesHeejin Ahn2018-09-111-0/+1
| | | | | | Without this builds with `-DLLVM_LINK_LLVM_DYLIB=ON` fail. llvm-svn: 341899
* [XRay] Add the `llvm-xray fdr-dump` implementationDean Michael Berris2018-09-111-1/+2
| | | | | | | | | | | | | | | | | | | Summary: In this change, we implement a `BlockPrinter` which orders records in a Block that's been indexed by the `BlockIndexer`. This is used in the `llvm-xray fdr-dump` tool which ties together the various types and utilities we've been working on, to allow for inspection of XRay FDR mode traces both with and without verification. This change is the final step of the refactoring of D50441. Reviewers: mboerger, eizan Subscribers: mgorny, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D51846 llvm-svn: 341887
* [XRay] Add a BlockVerifier visitor for FDR RecordsDean Michael Berris2018-09-101-0/+2
| | | | | | | | | | | | | | | | | | | | | | Summary: This patch implements a `BlockVerifier` type which enforces the invariants of the log structure of FDR mode logs on a per-block basis. This ensures that the data we encounter from an FDR mode log semantically correct (i.e. that records follow the documented "grammar" for FDR mode log records). This is another part of the refactoring of D50441. This is a slightly modified version of rL341628, avoiding the `std::tuple<...>` constructor that is not constexpr in C++11. Reviewers: mboerger, eizan Subscribers: mgorny, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D51723 llvm-svn: 341769
* Revert "[XRay] Add a BlockVerifier visitor for FDR Records"Dean Michael Berris2018-09-071-2/+0
| | | | | | This reverts commit r341628. llvm-svn: 341631
* [XRay] Add a BlockVerifier visitor for FDR RecordsDean Michael Berris2018-09-071-0/+2
| | | | | | | | | | | | | | | | | | | Summary: This patch implements a `BlockVerifier` type which enforces the invariants of the log structure of FDR mode logs on a per-block basis. This ensures that the data we encounter from an FDR mode log semantically correct (i.e. that records follow the documented "grammar" for FDR mode log records). This is another part of the refactoring of D50441. Reviewers: mboerger, eizan Subscribers: mgorny, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D51723 llvm-svn: 341628
* [XRay] Add a BlockIndexer visitor for FDR Records.Dean Michael Berris2018-09-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | Summary: This change adds a `BlockIndexer` type which maintains pointers to records that belong to the same process+thread pairs. The indexing happens with order of appearance of records as they are visited. This version of the indexer currently only supports FDR version 3 logs, which contain `BufferExtent` records. We will add support for v2 and v1 logs in follow-up patches. This is another part of D50441. Reviewers: eizan, kpw, mboerger Reviewed By: mboerger Subscribers: mboerger, mgorny, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D51673 llvm-svn: 341518
* [XRay] Add a RecordPrinter visitor for FDR RecordsDean Michael Berris2018-09-051-1/+2
| | | | | | | | | | | | | | | | | Summary: This change adds a `RecordPrinter` type which does some basic text serialization of the FDR record instances. This is one component of the tool we're building to dump the records from an FDR mode log as-is. This is a small part of D50441. Reviewers: eizan, kpw Subscribers: mgorny, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D51672 llvm-svn: 341447
* [XRay] FDR Record Producer/Consumer ImplementationDean Michael Berris2018-08-311-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch defines two new base types called `RecordProducer` and `RecordConsumer` which have default implementations for convenience (particularly for testing). A `RecordProducer` implementation has one member function called `produce()` which serves as a factory constructor for `Record` instances. This code exercises the `RecordInitializer` code path in the implementation for `FileBasedRecordProducer`. A `RecordConsumer` has a single member function called `consume(...)` which, as the name implies, consumes instances of `std::unique_ptr<Record>`. We have two implementations, one of which is used in the test to generate a vector of `std::unique_ptr<Record>` similar to how the `LogBuilder` implementation works. We introduce a test in `FDRProducerConsumerTest` which ensures that records we write through the `FDRTraceWriter` can be loaded by the `FileBasedRecordProducer`. The record(s) loaded this way are written again through the `FDRTraceWriter` into a separate string, which we then compare. This ensures that the read-in bytes to create the `Record` instances in memory can be replicated when written out through the `FDRTraceWriter`. This change depends on D51210 and is part of the refactoring of D50441 into smaller, more focused changes. Reviewers: eizan, kpw Subscribers: mgorny, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D51289 llvm-svn: 341180
* [XRay] FDRTraceWriter and FDR Trace LoadingDean Michael Berris2018-08-301-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is the first step in the larger refactoring and reduction of D50441. This step in the process does the following: - Introduces more granular types of `Record`s representing the many kinds of records written/read by the Flight Data Recorder (FDR) mode `Trace` loading function(s). - Introduces an abstract `RecordVisitor` type meant to handle the processing of the various `Record` derived types. This `RecordVisitor` has two implementations in this patch: `RecordInitializer` and `FDRTraceWriter`. - We also introduce a convenience interface for building a collection of `Record` instances called a `LogBuilder`. This allows us to generate sequences of `Record` instances manually (used in unit tests but useful otherwise). - The`FDRTraceWriter` class implements the `RecordVisitor` interface and handles the writing of metadata records to a `raw_ostream`. We demonstrate that in the unit test, we can generate in-memory FDR mode traces using the specific `Record` derived types, which we load through the `loadTrace(...)` function yielding valid `Trace` objects. This patch introduces the required types and concepts for us to start replacing the logic implemented in the `loadFDRLog` function to use the more granular types. In subsequent patches, we will introduce more visitor implementations which isolate the verification, printing, indexing, production/consumption, and finally the conversion of the FDR mode logs. The overarching goal of these changes is to make handling FDR mode logs better tested, more understandable, more extensible, and more systematic. This will also allow us to better represent the execution trace, as we improve the fidelity of the events we represent in an XRay `Trace` object, which we intend to do after FDR mode log processing is in better shape. Reviewers: eizan Reviewed By: eizan Subscribers: mgorny, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D51210 llvm-svn: 341029
* [XRay][llvm] Load XRay ProfilesDean Michael Berris2018-08-301-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change implements the profile loading functionality in LLVM to support XRay's profiling mode in compiler-rt. We introduce a type named `llvm::xray::Profile` which allows building a profile representation. We can load an XRay profile from a file to build Profile instances, or do it manually through the Profile type's API. The intent is to get the `llvm-xray` tool to generate `Profile` instances and use that as the common abstraction through which all conversion and analysis can be done. In the future we can generate `Profile` instances from `Trace` instances as well, through conversion functions. Some of the key operations supported by the `Profile` API are: - Path interning (`Profile::internPath(...)`) which returns a unique path identifier. - Block appending (`Profile::addBlock(...)`) to add thread-associated profile information. - Path ID to Path lookup (`Profile::expandPath(...)`) to look up a PathID and return the original interned path. - Block iteration. A 'Path' in this context represents the function call stack in leaf-to-root order. This is represented as a path in an internally managed prefix tree in the `Profile` instance. Having a handle (PathID) to identify the unique Paths we encounter for a particular Profile allows us to reduce the amount of memory required to associate profile data to a particular Path. This is the first of a series of patches to migrate the `llvm-stacks` tool towards using a single profile representation. Depends on D48653. Reviewers: kpw, eizan Reviewed By: kpw Subscribers: kpw, thakis, mgorny, llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D48370 llvm-svn: 341012
* Reverted r338825 and all the following tries to fix issues introduced by ↵Galina Kistanova2018-08-041-2/+0
| | | | | | | | that commit (r338826, r338827, r338829, r338880). This commit has broken build bots and has been left unattended for too long. llvm-svn: 338948
* convert some tabs to spacesNico Weber2018-08-031-2/+2
| | | | llvm-svn: 338880
* [XRay][llvm] Load XRay ProfilesDean Michael Berris2018-08-031-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change implements the profile loading functionality in LLVM to support XRay's profiling mode in compiler-rt. We introduce a type named `llvm::xray::Profile` which allows building a profile representation. We can load an XRay profile from a file to build Profile instances, or do it manually through the Profile type's API. The intent is to get the `llvm-xray` tool to generate `Profile` instances and use that as the common abstraction through which all conversion and analysis can be done. In the future we can generate `Profile` instances from `Trace` instances as well, through conversion functions. Some of the key operations supported by the `Profile` API are: - Path interning (`Profile::internPath(...)`) which returns a unique path identifier. - Block appending (`Profile::addBlock(...)`) to add thread-associated profile information. - Path ID to Path lookup (`Profile::expandPath(...)`) to look up a PathID and return the original interned path. - Block iteration. A 'Path' in this context represents the function call stack in leaf-to-root order. This is represented as a path in an internally managed prefix tree in the `Profile` instance. Having a handle (PathID) to identify the unique Paths we encounter for a particular Profile allows us to reduce the amount of memory required to associate profile data to a particular Path. This is the first of a series of patches to migrate the `llvm-stacks` tool towards using a single profile representation. Depends on D48653. Reviewers: kpw, eizan Reviewed By: kpw Subscribers: mgorny, llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D48370 llvm-svn: 338825
* Inline a few CMake variables into their only uses.Nico Weber2018-05-141-5/+1
| | | | | | No behavior change. Makes unittests CMakeLists.txt files more self-consistent. llvm-svn: 332280
* [XRay] A graph Class for the llvm-xray graphDean Michael Berris2017-02-101-0/+13
| | | | | | | | | | | | | | | | | | | Summary: In preparation for graph comparison and filtering, this is a library for representing graphs in LLVM. This will enable easier encapsulation and reuse of graphs in llvm-xray. Depends on D28999, D28225 Reviewers: dblaikie, dberris Reviewed By: dberris Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D29005 llvm-svn: 294717
* Revert "[XRay] A graph Class for the llvm-xray graph"Dean Michael Berris2017-02-101-13/+0
| | | | | | Broke tests, reverting. llvm-svn: 294714
* [XRay] A graph Class for the llvm-xray graphDean Michael Berris2017-02-101-0/+13
Summary: In preparation for graph comparison and filtering, this is a library for representing graphs in LLVM. This will enable easier encapsulation and reuse of graphs in llvm-xray. Depends on D28999, D28225 Reviewers: dblaikie, dberris Reviewed By: dberris Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D29005 llvm-svn: 294713
OpenPOWER on IntegriCloud