[llvm] r333354 - Tidy some language in the xray documentation.

[Eric Christopher via llvm-commits]

Author: echristo
Date: Sun May 27 02:19:03 2018
New Revision: 333354

URL: http://llvm.org/viewvc/llvm-project?rev=333354&view=rev
Log:
Tidy some language in the xray documentation.

Modified:
    llvm/trunk/docs/XRayExample.rst
    llvm/trunk/docs/XRayFDRFormat.rst

Modified: llvm/trunk/docs/XRayExample.rst
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/XRayExample.rst?rev=333354&r1=333353&r2=333354&view=diff
==============================================================================
--- llvm/trunk/docs/XRayExample.rst (original)
+++ llvm/trunk/docs/XRayExample.rst Sun May 27 02:19:03 2018
@@ -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 sp
 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 instrum
 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
 
 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.
 

Modified: llvm/trunk/docs/XRayFDRFormat.rst
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/XRayFDRFormat.rst?rev=333354&r1=333353&r2=333354&view=diff
==============================================================================
--- llvm/trunk/docs/XRayFDRFormat.rst (original)
+++ llvm/trunk/docs/XRayFDRFormat.rst Sun May 27 02:19:03 2018
@@ -15,7 +15,7 @@ When gathering XRay traces in Flight Dat
 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 th
 - ``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.