summaryrefslogtreecommitdiffstats
path: root/llvm/tools/llvm-xray/CMakeLists.txt
Commit message (Collapse)AuthorAgeFilesLines
* Break false dependencies on target librariesDaniel Sanders2019-05-231-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: For the most part this consists of replacing ${LLVM_TARGETS_TO_BUILD} with some combination of AllTargets* so that they depend on specific components of a target backend rather than all of it. The overall effect of this is that, for example, tools like opt no longer falsely depend on the disassembler, while tools like llvm-ar no longer depend on the code generator. There's a couple quirks to point out here: * AllTargetsCodeGens is a bit more prevalent than expected. Tools like dsymutil seem to need it which I was surprised by. * llvm-xray linked to all the backends but doesn't seem to need any of them. It builds and passes the tests so that seems to be correct. * I left gold out as it's not built when binutils is not available so I'm unable to test it Reviewers: bogner, JDevlieghere Reviewed By: bogner Subscribers: mehdi_amini, mgorny, steven_wu, dexonsmith, rupprecht, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62331 llvm-svn: 361567
* [XRay] Add the `llvm-xray fdr-dump` implementationDean Michael Berris2018-09-111-0/+1
| | | | | | | | | | | | | | | | | | | 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
* Inline contents of LLVM_XRAY_TOOLS variable into its only use.Nico Weber2018-05-091-8/+4
| | | | | | | No behavior change. https://reviews.llvm.org/D46402 llvm-svn: 331830
* use LLVM's standard CMakeLists.txt layout for llvm-xrayNico Weber2018-05-031-3/+8
| | | | llvm-svn: 331455
* [XRay][tools] Rename llvm-xray filenames from .cc -> .cpp (NFC)Dean Michael Berris2018-05-021-10/+10
| | | | | | | | | | | | | | | | Summary: This brings the filenames in accordance to the style guide and LLVM conventions for C++ filenames. As suggested by rnk@ in D46068. Reviewers: rnk Subscribers: mgorny, mgrang, llvm-commits Differential Revision: https://reviews.llvm.org/D46301 llvm-svn: 331321
* Don't list a source file twice.Nico Weber2018-04-251-1/+0
| | | | llvm-svn: 330845
* [XRay][tools] Function call stack based analysis tooling for XRay tracesKeith Wyss2017-09-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Second try after fixing a code san problem with iterator reference types. This change introduces a subcommand to the llvm-xray tool called "stacks" which allows for analysing XRay traces provided as inputs and accounting time to stacks instead of just individual functions. This gives us a more precise view of where in a program the latency is actually attributed. The tool uses a trie data structure to keep track of the caller-callee relationships as we process the XRay traces. In particular, we keep track of the function call stack as we enter functions. While we're doing this we're adding nodes in a trie and indicating a "calls" relatinship between the caller (current top of the stack) and the callee (the new top of the stack). When we push function ids onto the stack, we keep track of the timestamp (TSC) for the enter event. When exiting functions, we are able to account the duration by getting the difference between the timestamp of the exit event and the corresponding entry event in the stack. This works even if we somehow miss the exit events for intermediary functions (i.e. if the exit event is not cleanly associated with the enter event at the top of the stack). The output of the tool currently provides just the top N leaf functions that contribute the most latency, and the top N stacks that have the most frequency. In the future we can provide more sophisticated query mechanisms and potentially an export to database feature to make offline analysis of the stack traces possible with existing tools. Differential revision: D34863 llvm-svn: 312733
* Revert "[XRay][tools] Function call stack based analysis tooling for XRay ↵Keith Wyss2017-09-031-1/+0
| | | | | | | | | | traces" This reverts commit 204a65e0702847a1880336372ad7abd1df414b44. Double ref qualifier failed bots. llvm-svn: 312428
* [XRay][tools] Function call stack based analysis tooling for XRay tracesKeith Wyss2017-09-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change introduces a subcommand to the llvm-xray tool called "stacks" which allows for analysing XRay traces provided as inputs and accounting time to stacks instead of just individual functions. This gives us a more precise view of where in a program the latency is actually attributed. The tool uses a trie data structure to keep track of the caller-callee relationships as we process the XRay traces. In particular, we keep track of the function call stack as we enter functions. While we're doing this we're adding nodes in a trie and indicating a "calls" relatinship between the caller (current top of the stack) and the callee (the new top of the stack). When we push function ids onto the stack, we keep track of the timestamp (TSC) for the enter event. When exiting functions, we are able to account the duration by getting the difference between the timestamp of the exit event and the corresponding entry event in the stack. This works even if we somehow miss the exit events for intermediary functions (i.e. if the exit event is not cleanly associated with the enter event at the top of the stack). The output of the tool currently provides just the top N leaf functions that contribute the most latency, and the top N stacks that have the most frequency. In the future we can provide more sophisticated query mechanisms and potentially an export to database feature to make offline analysis of the stack traces possible with existing tools. llvm-svn: 312426
* [XRay] A tool for Comparing xray function call graphsDean Michael Berris2017-04-241-0/+1
| | | | | | | | | | | | | | | | | | | | | | Summary: This is a tool for comparing the function graphs produced by the llvm-xray graph too. It takes the form of a new subcommand of the llvm-xray tool 'graph-diff'. This initial version of the patch is very rough, but it is close to feature complete. Depends on D29363 Reviewers: dblaikie, dberris Reviewed By: dberris Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D29320 llvm-svn: 301160
* [XRAY] A Color Choosing helper for XRay GraphDean Michael Berris2017-02-251-0/+1
| | | | | | | | | | | | | | | | | | | Summary: In Preparation for graph comparison, this patch breaks out the color choice code from xray-graph into a library and adds polynomials for the Sequential and Difference sets from ColorBrewer. Depends on D29005 Reviewers: dblaikie, chandlerc, dberris Reviewed By: dberris Subscribers: chandlerc, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D29363 llvm-svn: 296210
* [XRay] Implement the `llvm-xray graph` subcommandDavid Blaikie2017-01-161-0/+1
| | | | | | | | | | | | Here we define the `graph` subcommand which generates a graph from the function call information and uses it to present the call information graphically with additional annotations. Reviewers: dblaikie, dberris Differential Revision: https://reviews.llvm.org/D27243 llvm-svn: 292156
* [XRay] Implement the `llvm-xray account` subcommandDean Michael Berris2017-01-121-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is the third of a multi-part change to implement subcommands for the `llvm-xray` tool. Here we define the `account` subcommand which does simple function call accounting, generating basic statistics on function calls we find in an XRay log/trace. We support text output and csv output for this subcommand. This change also supports sorting, summing, and filtering the top N results. Part of this tool will later be turned into a library that could be used for basic function call accounting. Depends on D24376. Reviewers: dblaikie, echristo Subscribers: mehdi_amini, dberris, beanz, llvm-commits Differential Revision: https://reviews.llvm.org/D24377 llvm-svn: 291749
* [XRay] Define the library for XRay trace logsDean Michael Berris2017-01-111-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In this change we move the definition of the log reading routines from the tools directory in LLVM to {include/llvm,lib}/XRay. We improve the documentation a little bit for the publicly accessible headers, and adjust the top-matter. This also leads to some refactoring and cleanup in the tooling code. In particular, we do the following: - Rename the class from LogReader to Trace, as it better represents the logical set of records as opposed to a log. - Use file type detection instead of asking the user to say what format the input file is. This allows us to keep the interface simple and encapsulate the logic of loading the data appropriately. In future changes we increase the API surface and write dedicated unit tests for the XRay library. Depends on D24376. Reviewers: dblaikie, echristo Subscribers: mehdi_amini, mgorny, llvm-commits, varno Differential Revision: https://reviews.llvm.org/D28345 llvm-svn: 291652
* [XRay] Implement `llvm-xray convert` -- trace file conversionDean Michael Berris2017-01-101-1/+7
| | | | | | | | | | | | | | | | | | | | This is the second part of a multi-part change to define additional subcommands to the `llvm-xray` tool. This change defines a conversion subcommand to take XRay log files, and turns them from one format to another (binary or YAML). This currently only supports the first version of the log file format, defined in the compiler-rt runtime. Depends on D21987. Reviewers: dblaikie, echristo Subscribers: mehdi_amini, dberris, beanz, llvm-commits Differential Revision: https://reviews.llvm.org/D24376 llvm-svn: 291529
* [XRay] Implement `llvm-xray extract`, start of the llvm-xray toolDean Michael Berris2016-10-261-0/+10
| | | | | | | | | | | | | | | | | | | | Usage: llvm-xray extract <object file> [-o <filename or '-'>] The tool gets the XRay instrumentation map from an object file and turns it into YAML. We first support ELF64 sleds on x86_64 binaries, with provision for supporting other supported platforms and formats later. This is the first of a many-part change to fully implement the `llvm-xray` tool. We also define a subcommand registration and dispatch mechanism to be used by other further subcommand implementations for llvm-xray. Diffusion Revision: https://reviews.llvm.org/D21987 llvm-svn: 285165
* Revert "[XRay] Implement `llvm-xray extract`, start of the llvm-xray tool"Dean Michael Berris2016-10-261-10/+0
| | | | | | Reverts r285155 -- misconfigured tests. llvm-svn: 285156
* [XRay] Implement `llvm-xray extract`, start of the llvm-xray toolDean Michael Berris2016-10-261-0/+10
Usage: llvm-xray extract <object file> [-o <filename or '-'>] The tool gets the XRay instrumentation map from an object file and turns it into YAML. We first support ELF64 sleds on x86_64 binaries, with provision for supporting other supported platforms and formats later. This is the first of a many-part change to fully implement the `llvm-xray` tool. We also define a subcommand registration and dispatch mechanism to be used by other further subcommand implementations for llvm-xray. llvm-svn: 285155
OpenPOWER on IntegriCloud