summaryrefslogtreecommitdiffstats
path: root/llvm/tools/llvm-xray
Commit message (Collapse)AuthorAgeFilesLines
* [xray] Remove cl::sub from alias optionsShoaib Meenai2020-01-096-78/+41
| | | | | | | | | | | | | | | | | | | Currently running the xray tools generates a number of errors: $ ./bin/llvm-xray : for the -k option: cl::alias must not have cl::sub(), aliased option's cl::sub() will be used! : for the -d option: cl::alias must not have cl::sub(), aliased option's cl::sub() will be used! : for the -o option: cl::alias must not have cl::sub(), aliased option's cl::sub() will be used! : for the -f option: cl::alias must not have cl::sub(), aliased option's cl::sub() will be used! : for the -s option: cl::alias must not have cl::sub(), aliased option's cl::sub() will be used! : for the -r option: cl::alias must not have cl::sub(), aliased option's cl::sub() will be used! : for the -p option: cl::alias must not have cl::sub(), aliased option's cl::sub() will be used! : for the -m option: cl::alias must not have cl::sub(), aliased option's cl::sub() will be used! <snip> Patch by Ryan Mansfield. Differential Revision: https://reviews.llvm.org/D69386
* [llvm-objdump] Add warning messages if disassembly + source for problematic ↵Michael Pozulp2019-08-151-1/+1
| | | | | | | | | | | | | | | | | | inputs Summary: Addresses https://bugs.llvm.org/show_bug.cgi?id=41905 Reviewers: jhenderson, rupprecht, grimar Reviewed By: jhenderson, grimar Subscribers: RKSimon, MaskRay, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62462 llvm-svn: 368963
* Switch LLVM to use 64-bit offsets (2/5)Igor Kudrin2019-08-061-1/+1
| | | | | | | | | This updates all libraries and tools in LLVM Core to use 64-bit offsets which directly or indirectly come to DataExtractor. Differential Revision: https://reviews.llvm.org/D65638 llvm-svn: 368014
* Revert "[llvm-objdump] Re-commit r367284."Michael Pozulp2019-08-051-1/+1
| | | | | | | | This reverts r367776 (git commit d34099926e909390cb0254bebb4b7f5cf15467c7). My changes to llvm-objdump tests caused them to fail on windows: http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/27368 llvm-svn: 367816
* Rename F_{None,Text,Append} to OF_{None,Text,Append}. NFCFangrui Song2019-08-055-6/+6
| | | | | | F_{None,Text,Append} are kept for compatibility since r334221. llvm-svn: 367800
* [llvm-objdump] Re-commit r367284.Michael Pozulp2019-08-041-1/+1
| | | | | | | | | | | | | | | | | | Add warning messages if disassembly + source for problematic inputs Summary: Addresses https://bugs.llvm.org/show_bug.cgi?id=41905 Reviewers: jhenderson, rupprecht, grimar Reviewed By: jhenderson, grimar Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62462 llvm-svn: 367776
* Revert "[llvm-objdump] Add warning messages if disassembly + source for ↵Michael Pozulp2019-07-301-1/+1
| | | | | | | | | | problematic inputs" This reverts r367284 (git commit b1cbe51bdf44098c74f5c74b7bcd8c041a7c6772). My changes to LLVMSymbolizer caused a test to fail: http://lab.llvm.org:8011/builders/clang-ppc64be-linux-lnt/builds/29488 llvm-svn: 367286
* [llvm-objdump] Add warning messages if disassembly + source for problematic ↵Michael Pozulp2019-07-301-1/+1
| | | | | | | | | | | | | | | | | | inputs Summary: Addresses https://bugs.llvm.org/show_bug.cgi?id=41905 Reviewers: jhenderson, rupprecht, grimar Reviewed By: jhenderson, grimar Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62462 llvm-svn: 367284
* [Support] Move llvm::MemoryBuffer to sys::fs::file_tReid Kleckner2019-07-101-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: On Windows, Posix integer file descriptors are a compatibility layer over native file handles provided by the C runtime. There is a hard limit on the maximum number of file descriptors that a process can open, and the limit is 8192. LLD typically doesn't run into this limit because it opens input files, maps them into memory, and then immediately closes the file descriptor. This prevents it from running out of FDs. For various reasons, I'd like to open handles to every input file and keep them open during linking. That requires migrating MemoryBuffer over to taking open native file handles instead of integer FDs. Reviewers: aganea, Bigcheese Reviewed By: aganea Subscribers: smeenai, silvas, mehdi_amini, hiraditya, steven_wu, dexonsmith, dang, llvm-commits, zturner Tags: #llvm Differential Revision: https://reviews.llvm.org/D63453 llvm-svn: 365588
* [xray] Remove usage of procid_tAlexandre Ganea2019-06-262-12/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D61946 llvm-svn: 364439
* Simplify std::lower_bound with llvm::{bsearch,lower_bound}. NFCFangrui Song2019-06-211-4/+2
| | | | llvm-svn: 364006
* Symbolize: Replace the Options constructor with in-class initialization. NFCI.Peter Collingbourne2019-06-115-15/+5
| | | | | | | | This is not only less code but also clearer at the use site. Differential Revision: https://reviews.llvm.org/D63113 llvm-svn: 363024
* 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
* [DebugInfo] add SectionedAddress to DebugInfo interfaces.Alexey Lapshin2019-02-271-2/+12
| | | | | | | | | | | | | | | | | That patch is the fix for https://bugs.llvm.org/show_bug.cgi?id=40703 "wrong line number info for obj file compiled with -ffunction-sections" bug. The problem happened with only .o files. If object file contains several .text sections then line number information showed incorrectly. The reason for this is that DwarfLineTable could not detect section which corresponds to specified address(because address is the local to the section). And as the result it could not select proper sequence in the line table. The fix is to pass SectionIndex with the address. So that it would be possible to differentiate addresses from various sections. With this fix llvm-objdump shows correct line numbers for disassembled code. Differential review: https://reviews.llvm.org/D58194 llvm-svn: 354972
* [XRay][tools] Revert "Use Support/JSON.h in llvm-xray convert"Roman Lebedev2019-02-251-48/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This reverts D50129 / rL338834: [XRay][tools] Use Support/JSON.h in llvm-xray convert Abstractions are great. Readable code is great. JSON support library is a *good* idea. However unfortunately, there is an internal detail that one needs to be aware of in `llvm::json::Object` - it uses `llvm::DenseMap`. So for **every** `llvm::json::Object`, even if you only store a single `int` entry there, you pay the whole price of `llvm::DenseMap`. Unfortunately, it matters for `llvm-xray`. I was trying to analyse the `llvm-exegesis` analysis mode performance, and for that i wanted to view the LLVM X-Ray log visualization in Chrome trace viewer. And the `llvm-xray convert` is sluggish, and sometimes even ended up being killed by OOM. `xray-log.llvm-exegesis.lwZ0sT` was acquired from `llvm-exegesis` (compiled with ` -fxray-instruction-threshold=128`) analysis mode over `-benchmarks-file` with 10099 points (one full latency measurement set), with normal runtime of 0.387s. Timings: Old: (copied from D58580) ``` $ perf stat -r 5 ./bin/llvm-xray convert -sort -symbolize -instr_map=./bin/llvm-exegesis -output-format=trace_event -output=/tmp/trace.yml xray-log.llvm-exegesis.lwZ0sT Performance counter stats for './bin/llvm-xray convert -sort -symbolize -instr_map=./bin/llvm-exegesis -output-format=trace_event -output=/tmp/trace.yml xray-log.llvm-exegesis.lwZ0sT' (5 runs): 21346.24 msec task-clock # 1.000 CPUs utilized ( +- 0.28% ) 314 context-switches # 14.701 M/sec ( +- 59.13% ) 1 cpu-migrations # 0.037 M/sec ( +-100.00% ) 2181354 page-faults # 102191.251 M/sec ( +- 0.02% ) 85477442102 cycles # 4004415.019 GHz ( +- 0.28% ) (83.33%) 14526427066 stalled-cycles-frontend # 16.99% frontend cycles idle ( +- 0.70% ) (83.33%) 32371533721 stalled-cycles-backend # 37.87% backend cycles idle ( +- 0.27% ) (33.34%) 67896890228 instructions # 0.79 insn per cycle # 0.48 stalled cycles per insn ( +- 0.03% ) (50.00%) 14592654840 branches # 683631198.653 M/sec ( +- 0.02% ) (66.67%) 212207534 branch-misses # 1.45% of all branches ( +- 0.94% ) (83.34%) 21.3502 +- 0.0585 seconds time elapsed ( +- 0.27% ) ``` New: ``` $ perf stat -r 9 ./bin/llvm-xray convert -sort -symbolize -instr_map=./bin/llvm-exegesis -output-format=trace_event -output=/tmp/trace.yml xray-log.llvm-exegesis.lwZ0sT Performance counter stats for './bin/llvm-xray convert -sort -symbolize -instr_map=./bin/llvm-exegesis -output-format=trace_event -output=/tmp/trace.yml xray-log.llvm-exegesis.lwZ0sT' (9 runs): 7178.38 msec task-clock # 1.000 CPUs utilized ( +- 0.26% ) 182 context-switches # 25.402 M/sec ( +- 28.84% ) 0 cpu-migrations # 0.046 M/sec ( +- 70.71% ) 33701 page-faults # 4694.994 M/sec ( +- 0.88% ) 28761053971 cycles # 4006833.933 GHz ( +- 0.26% ) (83.32%) 2028297997 stalled-cycles-frontend # 7.05% frontend cycles idle ( +- 1.61% ) (83.32%) 10773154901 stalled-cycles-backend # 37.46% backend cycles idle ( +- 0.38% ) (33.36%) 36199132874 instructions # 1.26 insn per cycle # 0.30 stalled cycles per insn ( +- 0.03% ) (50.02%) 6434504227 branches # 896420204.421 M/sec ( +- 0.03% ) (66.68%) 73355176 branch-misses # 1.14% of all branches ( +- 1.46% ) (83.33%) 7.1807 +- 0.0190 seconds time elapsed ( +- 0.26% ) ``` So using `llvm::json` nearly triples run-time on that test case. (+3x is times, not percent.) Memory: Old: ``` total runtime: 39.88s. bytes allocated in total (ignoring deallocations): 79.07GB (1.98GB/s) calls to allocation functions: 33267816 (834135/s) temporary memory allocations: 5832298 (146235/s) peak heap memory consumption: 9.21GB peak RSS (including heaptrack overhead): 147.98GB total memory leaked: 1.09MB ``` New: ``` total runtime: 17.42s. bytes allocated in total (ignoring deallocations): 5.12GB (293.86MB/s) calls to allocation functions: 21382982 (1227284/s) temporary memory allocations: 232858 (13364/s) peak heap memory consumption: 350.69MB peak RSS (including heaptrack overhead): 2.55GB total memory leaked: 79.95KB ``` Diff: ``` total runtime: -22.46s. bytes allocated in total (ignoring deallocations): -73.95GB (3.29GB/s) calls to allocation functions: -11884834 (529155/s) temporary memory allocations: -5599440 (249307/s) peak heap memory consumption: -8.86GB peak RSS (including heaptrack overhead): 0B total memory leaked: -1.01MB ``` So using `llvm::json` increases *peak* memory consumption on *this* testcase ~+27x. And total allocation count +15x. Both of these numbers are times, *not* percent. And note that memory usage is clearly unbound with `llvm::json`, it directly depends on the length of the log, so peak memory consumption is always increasing. This isn't so with the dumb code, there is no accumulating memory consumption, peak memory consumption is fixed. Naturally, that means it will handle *much* larger logs without OOM'ing. Readability is good, but the price is simply unacceptable here. Too bad none of this analysis was done as part of the development/review D50129 itself. Reviewers: dberris, kpw, sammccall Reviewed By: dberris Subscribers: riccibruno, hans, courbet, jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D58584 llvm-svn: 354764
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-1919-76/+57
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [XRay] Add a helper function sortByKey to simplify codeFangrui Song2018-12-111-68/+31
| | | | | | | | | | | | Reviewers: dberris, mboerger Reviewed By: dberris Subscribers: mgrang, llvm-commits Differential Revision: https://reviews.llvm.org/D55548 llvm-svn: 348869
* [Support] Make error banner optional in logAllUnhandledErrorsJonas Devlieghere2018-11-111-1/+1
| | | | | | | | In a lot of places an empty string was passed as the ErrorBanner to logAllUnhandledErrors. This patch makes that argument optional to simplify the call sites. llvm-svn: 346604
* [XRay] Update XRayRecord to support Custom/Typed EventsDean Michael Berris2018-11-064-18/+46
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change cuts across LLVM and compiler-rt to add support for rendering custom events in the XRayRecord type, to allow for including user-provided annotations in the output YAML (as raw bytes). This work enables us to add custom event and typed event records into the `llvm::xray::Trace` type for user-provided events. This can then be programmatically handled through the C++ API and can be included in some of the tooling as well. For now we support printing the raw data we encounter in the custom events in the converted output. Future work will allow us to start interpreting these custom and typed events through a yet-to-be-defined API for extending the trace analysis library. Reviewers: mboerger Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D54139 llvm-svn: 346214
* llvm::sort(C.begin(), C.end(), ...) -> llvm::sort(C, ...)Fangrui Song2018-09-271-67/+64
| | | | | | | | | | | | Summary: The convenience wrapper in STLExtras is available since rL342102. Reviewers: dblaikie, javed.absar, JDevlieghere, andreadb Subscribers: MatzeB, sanjoy, arsenm, dschuff, mehdi_amini, sdardis, nemanjai, jvesely, nhaehnle, sbc100, jgravelle-google, eraman, aheejin, kbarton, JDevlieghere, javed.absar, gbedwell, jrtc27, mgrang, atanasyan, steven_wu, george.burgess.iv, dexonsmith, kristina, jsji, llvm-commits Differential Revision: https://reviews.llvm.org/D52573 llvm-svn: 343163
* [Xray] llvm-xray fix possible segfaultDavid Carlier2018-09-181-2/+5
| | | | | | | | | | | | top argument when superior to the instrumentated code list capacity can lead to a segfault. Reviewers: dberris Reviewed By: dberris Differential Revision: https://reviews.llvm.org/D52224 llvm-svn: 342461
* [XRay] Add the `llvm-xray fdr-dump` implementationDean Michael Berris2018-09-112-0/+120
| | | | | | | | | | | | | | | | | | | 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][tools] Use Support/JSON.h in llvm-xray convertDean Michael Berris2018-08-031-61/+48
| | | | | | | | | | | | | | | | | | Summary: This change removes the ad-hoc implementation used by llvm-xray's `convert` subcommand to generate JSON encoded catapult (AKA Chrome Trace Viewer) trace output, to instead use the JSON encoder now in the Support library. Reviewers: kpw, zturner, eizan Reviewed By: kpw Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D50129 llvm-svn: 338834
* llvm-xray: Broken chrome trace event format outputDean Michael Berris2018-07-241-0/+3
| | | | | | | | | | | | | | | | Summary: Missing comma separator for EXIT and TAIL_EXIT RecordTypes emit invalid JSON output for Chrome Trace Event Format. Reviewers: dberris Reviewed By: dberris Subscribers: sammccall, kpw, llvm-commits Differential Revision: https://reviews.llvm.org/D49687 llvm-svn: 337795
* [XRay][compiler-rt] Add PID field to llvm-xray tool and add PID metadata ↵Dean Michael Berris2018-07-132-18/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | record entry in FDR mode Summary: llvm-xray changes: - account-mode - process-id {...} shows after thread-id - convert-mode - process {...} shows after thread - parses FDR and basic mode pid entries - Checks version number for FDR log parsing. Basic logging changes: - Update header version from 2 -> 3 FDR logging changes: - Update header version from 2 -> 3 - in writeBufferPreamble, there is an additional PID Metadata record (after thread id record and tsc record) Test cases changes: - fdr-mode.cc, fdr-single-thread.cc, fdr-thread-order.cc modified to catch process id output in the log. Reviewers: dberris Reviewed By: dberris Subscribers: hiraditya, llvm-commits, #sanitizers Differential Revision: https://reviews.llvm.org/D49153 llvm-svn: 336974
* Clean up some code in Program.Zachary Turner2018-06-082-6/+4
| | | | | | | | | | NFC here, this just raises some platform specific ifdef hackery out of a class and creates proper platform-independent typedefs for the relevant things. This allows these typedefs to be reused in other places without having to reinvent this preprocessor logic. llvm-svn: 334294
* Support: Simplify endian stream interface. NFCI.Peter Collingbourne2018-05-181-1/+1
| | | | | | | | | | | | Provide some free functions to reduce verbosity of endian-writing a single value, and replace the endianness template parameter with a field. Part of PR37466. Differential Revision: https://reviews.llvm.org/D47032 llvm-svn: 332757
* 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-0211-19/+19
| | | | | | | | | | | | | | | | 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
* [tools] Change std::sort to llvm::sort in response to r327219Mandeep Singh Grang2018-04-011-67/+67
| | | | | | | | | | | | | | | | | | | | | | Summary: r327219 added wrappers to std::sort which randomly shuffle the container before sorting. This will help in uncovering non-determinism caused due to undefined sorting order of objects having the same key. To make use of that infrastructure we need to invoke llvm::sort instead of std::sort. Note: This patch is one of a series of patches to replace *all* std::sort to llvm::sort. Refer the comments section in D44363 for a list of all the required patches. Reviewers: JDevlieghere, zturner, echristo, dberris, friss Reviewed By: echristo Subscribers: gbedwell, llvm-commits Differential Revision: https://reviews.llvm.org/D45141 llvm-svn: 328943
* [XRay] cache symbolized function names for a repeatedly queried function IDMartin Pelikan2018-03-012-1/+9
| | | | | | | | | | | | | | | | | | | Summary: Processing 2 GB XRay traces with "llvm-xray convert -symbolize" needs to go over each trace record and symbolize the function name refered to by its ID. Currently this happens by asking the LLVM symbolizer code every single time. A simple cache can save around 30 minutes of processing of that trace. llvm-xray's resident memory usage increased negligibly with this cache. Reviewers: dberris Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D43896 llvm-svn: 326407
* [XRay] fix 99th percentile lookups by sorting the array correctlyMartin Pelikan2018-01-301-2/+5
| | | | | | | | | | | | | | Summary: It was a copy-paste typo, sorting only to the 90th percentile twice. Now, it only sorts the array prefix once, and extracts what we need. Reviewers: dberris, kpw, eizan Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D42690 llvm-svn: 323800
* Remove redundant includes from tools.Michael Zolotukhin2017-12-134-15/+0
| | | | llvm-svn: 320631
* xray-record-yaml.h: Remove unused fileDavid Blaikie2017-11-211-102/+0
| | | | llvm-svn: 318715
* [XRay] Minimal tool to convert xray traces to Chrome's Trace Event Format.Keith Wyss2017-11-074-113/+375
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Minimal tool to convert xray traces to Chrome's Trace Event Format. Summary: Make use of Chrome Trace Event format's Duration events and stack frame dict to produce Json files that chrome://tracing can visualize from xray function call traces. Trace Event format is more robust and has several features like argument logging, function categorization, multi process traces, etc. that we can add as needed. Duration events cover an important base case. Part of this change is rearranging the code so that the TrieNode data structure can be used from multiple tools and can carry parameterized baggage on the nodes. I put the actual behavior changes in llvm-xray convert exclusively. Exploring the trace of instrumented llc was pretty nifty if overwhelming. I can envision this being very useful for analyzing contention scenarios or tuning parameters like batch sizes in a producer consumer queue. For more targeted traces likemthis, let's talk about how we want to approach trace pruning. Reviewers: dberris, pelikan Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D39362 llvm-svn: 317531
* Removing default case statement from covered switch.Keith Wyss2017-10-131-8/+0
| | | | | | | | | | | Previous patch did not count on the llvm command line parser to restrict the inputs, but it is safe to do so. Fix forward for patch with details: -- https://reviews.llvm.org/D38650 and -- https://llvm.org/svn/llvm-project/llvm/trunk@315635 91177308-0d34-0410-b5e6-96231b3b80d8 llvm-svn: 315644
* [XRay][tools] Updated stacks tool with flamegraph output.Keith Wyss2017-10-121-19/+217
| | | | | | | | | | | | | | | | | | | | | Summary: As the first step to allow analysis and visualization of xray collected data, allow using the llvm-xray stacks tool to emit a complete listing of stacks in the format consumable by a flamegraph tool. Possible follow up formats include chrome trace viewer format and sql load files. As a POC, I'm able to generate flamegraphs of an xray instrumented llc compiling hello world. Reviewers: dberris, pelikan Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D38650 llvm-svn: 315635
* [XRay] fix the -Werror build by handling all enum cases in switchesMartin Pelikan2017-09-272-1/+5
| | | | | | Followup to D32840. llvm-svn: 314270
* [XRay] convert FDR arg1 log entriesMartin Pelikan2017-09-273-3/+6
| | | | | | | | | | | | | | | | | | | | Summary: A new FDR metadata record will support logging a function call argument; appending multiple metadata records will represent a sequence of arguments meaning that "holes" are not representable by the buffer format. Each call argument is currently a 64-bit value (useful for "this" pointers and synchronization objects). If present, we put this argument to the function call "entry" record it belongs to, and alter its type to notify the user of its presence. Reviewers: dberris Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32840 llvm-svn: 314269
* [XRay][tools] Support tail-call exits before we write them in the runtimeDean Michael Berris2017-09-184-3/+12
| | | | | | | | | | | | | | | | | Summary: This change adds support for explicit tail-exit records to be written by the XRay runtime. This lets us differentiate the tail exit records/events in the log, and allows us to treat those exit events especially in the future. For now we allow printing those out in YAML (and reading them in). Reviewers: kpw, pelikan Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D37964 llvm-svn: 313514
* Don't call exit from cl::PrintHelpMessage.Rafael Espindola2017-09-071-0/+1
| | | | | | | | | Most callers were not expecting the exit(0) and trying to exit with a different value. This also adds back the call to cl::PrintHelpMessage in llvm-ar. llvm-svn: 312761
* [XRay][tools] Function call stack based analysis tooling for XRay tracesKeith Wyss2017-09-073-1/+636
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-033-636/+1
| | | | | | | | | | 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-033-1/+636
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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][tools] Fix an accounting bug in llvm-xray accountDean Michael Berris2017-08-311-3/+31
| | | | | | | | | | | | | | | | | | Summary: Before this patch, llvm-xray account will assume that thread stacks will not be empty. Unfortunately there are cases where an instrumented function will see a call to `fork()` which will cause the child process to not see the start of the function, but only see the end of the function. The tooling cannot assume that threads will always have perfect stacks, and so we change it to support this reality. Reviewers: dblaikie Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D31870 llvm-svn: 312204
* Move Object format code to lib/BinaryFormat.Zachary Turner2017-06-071-1/+1
| | | | | | | | | | | | This creates a new library called BinaryFormat that has all of the headers from llvm/Support containing structure and layout definitions for various types of binary formats like dwarf, coff, elf, etc as well as the code for identifying a file from its magic. Differential Revision: https://reviews.llvm.org/D33843 llvm-svn: 304864
* [XRay][tools] Remove wayward semicolon (NFC)Dean Michael Berris2017-04-261-1/+1
| | | | | | Follow-up to D29320. llvm-svn: 301378
* [XRay][tools] Fixup definition for stat division.Dean Michael Berris2017-04-261-3/+3
| | | | | | | | Copy-pasta error. Follow-up to D29320. llvm-svn: 301376
OpenPOWER on IntegriCloud