1
0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-22 10:42:39 +01:00

Tidy some language in the xray documentation.

llvm-svn: 333354
This commit is contained in:
Eric Christopher 2018-05-27 09:19:03 +00:00
parent e42a0f11bc
commit ee14ad5043
2 changed files with 15 additions and 17 deletions

View File

@ -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.

View File

@ -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.