From ee14ad5043fa538bdb91d2207ca6b4a72fbbca73 Mon Sep 17 00:00:00 2001 From: Eric Christopher Date: Sun, 27 May 2018 09:19:03 +0000 Subject: [PATCH] Tidy some language in the xray documentation. llvm-svn: 333354 --- docs/XRayExample.rst | 20 +++++++++----------- docs/XRayFDRFormat.rst | 12 ++++++------ 2 files changed, 15 insertions(+), 17 deletions(-) diff --git a/docs/XRayExample.rst b/docs/XRayExample.rst index eefb8cc8a43..e1b8c9b69d5 100644 --- a/docs/XRayExample.rst +++ b/docs/XRayExample.rst @@ -48,11 +48,11 @@ Getting Traces -------------- By default, XRay does not write out the trace files or patch the application -before main starts. If we just run ``llc`` it should just work like a normally -built binary. However, if we want to get a full trace of the application's -operations (of the functions we do end up instrumenting with XRay) then we need -to enable XRay at application start. To do this, XRay checks the -``XRAY_OPTIONS`` environment variable. +before main starts. If we run ``llc`` it should work like a normally built +binary. If we want to get a full trace of the application's operations (of the +functions we do end up instrumenting with XRay) then we need to enable XRay +at application start. To do this, XRay checks the ``XRAY_OPTIONS`` environment +variable. :: @@ -73,9 +73,8 @@ instrumented, and how much time we're spending in parts of the code. To make sense of this data, we use the ``llvm-xray`` tool which has a few subcommands to help us understand our trace. -One of the simplest things we can do is to get an accounting of the functions -that have been instrumented. We can see an example accounting with ``llvm-xray -account``: +One of the things we can do is to get an accounting of the functions that have +been instrumented. We can see an example accounting with ``llvm-xray account``: :: @@ -202,8 +201,7 @@ Given a trace, and optionally an instrumentation map, the ``llvm-xray stack`` command can be used to analyze a call stack graph constructed from the function call timeline. -The simplest way to use the command is simply to output the top stacks by call -count and time spent. +The way to use the command is to output the top stacks by call count and time spent. :: @@ -245,7 +243,7 @@ FlameGraph tool, currently available on `github To generate output for a flamegraph, a few more options are necessary. -- ``-all-stacks`` - Emits all of the stacks instead of just the top stacks. +- ``-all-stacks`` - Emits all of the stacks. - ``-stack-format`` - Choose the flamegraph output format 'flame'. - ``-aggregation-type`` - Choose the metric to graph. diff --git a/docs/XRayFDRFormat.rst b/docs/XRayFDRFormat.rst index f7942bc212d..46f72c54228 100644 --- a/docs/XRayFDRFormat.rst +++ b/docs/XRayFDRFormat.rst @@ -15,7 +15,7 @@ When gathering XRay traces in Flight Data Recorder mode, each thread of an application will claim buffers to fill with trace data, which at some point is finalized and flushed. -A goal of the profiler is to minimize overhead, so the flushed data directly +A goal of the profiler is to minimize overhead, the flushed data directly corresponds to the buffer. This document describes the format of a trace file. @@ -106,11 +106,11 @@ There are a few categories of data in the sequence. - ``Function Arguments``: The arguments to some functions are included in the trace. These are either pointer addresses or primitives that are read and logged independently of their types in a high level language. To the tracer, - they are all simply numbers. Function Records that have attached arguments - will indicate their presence on the function entry record. We only support - logging contiguous function argument sequences starting with argument zero, - which will be the "this" pointer for member function invocations. For example, - we don't support logging the first and third argument. + they are all numbers. Function Records that have attached arguments will + indicate their presence on the function entry record. We only support logging + contiguous function argument sequences starting with argument zero, which will + be the "this" pointer for member function invocations. For example, we don't + support logging the first and third argument. A reader of the memory format must maintain a state machine. The format makes no attempt to pad for alignment, and it is not seekable.