[llvm] Proofread OptBisect.rst (#162225)
This commit is contained in:
parent
2818df54a0
commit
2f66bcce13
@ -8,7 +8,7 @@ Using -opt-bisect-limit to debug optimization errors
|
||||
Introduction
|
||||
============
|
||||
|
||||
The -opt-bisect-limit option provides a way to disable all optimization passes
|
||||
The ``-opt-bisect-limit`` option provides a way to disable all optimization passes
|
||||
above a specified limit without modifying the way in which the Pass Managers
|
||||
are populated. The intention of this option is to assist in tracking down
|
||||
problems where incorrect transformations during optimization result in incorrect
|
||||
@ -19,10 +19,10 @@ skipped while still allowing correct code generation call a function to
|
||||
check the opt-bisect limit before performing optimizations. Passes which
|
||||
either must be run or do not modify the IR do not perform this check and are
|
||||
therefore never skipped. Generally, this means analysis passes, passes
|
||||
that are run at CodeGenOptLevel::None and passes which are required for register
|
||||
that are run at ``CodeGenOptLevel::None`` and passes which are required for register
|
||||
allocation.
|
||||
|
||||
The -opt-bisect-limit option can be used with any tool, including front ends
|
||||
The ``-opt-bisect-limit`` option can be used with any tool, including front ends
|
||||
such as clang, that uses the core LLVM library for optimization and code
|
||||
generation. The exact syntax for invoking the option is discussed below.
|
||||
|
||||
@ -36,7 +36,7 @@ transformations that is difficult to replicate with tools like opt and llc.
|
||||
Getting Started
|
||||
===============
|
||||
|
||||
The -opt-bisect-limit command line option can be passed directly to tools such
|
||||
The ``-opt-bisect-limit`` command-line option can be passed directly to tools such
|
||||
as opt, llc and lli. The syntax is as follows:
|
||||
|
||||
::
|
||||
@ -49,17 +49,17 @@ indicating the index value that is associated with that optimization. To skip
|
||||
optimizations, pass the value of the last optimization to be performed as the
|
||||
opt-bisect-limit. All optimizations with a higher index value will be skipped.
|
||||
|
||||
In order to use the -opt-bisect-limit option with a driver that provides a
|
||||
In order to use the ``-opt-bisect-limit`` option with a driver that provides a
|
||||
wrapper around the LLVM core library, an additional prefix option may be
|
||||
required, as defined by the driver. For example, to use this option with
|
||||
clang, the "-mllvm" prefix must be used. A typical clang invocation would look
|
||||
clang, the ``-mllvm`` prefix must be used. A typical clang invocation would look
|
||||
like this:
|
||||
|
||||
::
|
||||
|
||||
clang -O2 -mllvm -opt-bisect-limit=256 my_file.c
|
||||
|
||||
The -opt-bisect-limit option may also be applied to link-time optimizations by
|
||||
The ``-opt-bisect-limit`` option may also be applied to link-time optimizations by
|
||||
using a prefix to indicate that this is a plug-in option for the linker. The
|
||||
following syntax will set a bisect limit for LTO transformations:
|
||||
|
||||
@ -72,11 +72,11 @@ following syntax will set a bisect limit for LTO transformations:
|
||||
|
||||
LTO passes are run by a library instance invoked by the linker. Therefore any
|
||||
passes run in the primary driver compilation phase are not affected by options
|
||||
passed via '-Wl,-plugin-opt' and LTO passes are not affected by options
|
||||
passed to the driver-invoked LLVM invocation via '-mllvm'.
|
||||
passed via ``-Wl,-plugin-opt`` and LTO passes are not affected by options
|
||||
passed to the driver-invoked LLVM invocation via ``-mllvm``.
|
||||
|
||||
Passing ``-opt-bisect-print-ir-path=path/foo.ll`` will dump the IR to
|
||||
``path/foo.ll`` when -opt-bisect-limit starts skipping passes.
|
||||
``path/foo.ll`` when ``-opt-bisect-limit`` starts skipping passes.
|
||||
|
||||
Bisection Index Values
|
||||
======================
|
||||
@ -85,7 +85,7 @@ The granularity of the optimizations associated with a single index value is
|
||||
variable. Depending on how the optimization pass has been instrumented the
|
||||
value may be associated with as much as all transformations that would have
|
||||
been performed by an optimization pass on an IR unit for which it is invoked
|
||||
(for instance, during a single call of runOnFunction for a FunctionPass) or as
|
||||
(for instance, during a single call of ``runOnFunction`` for a ``FunctionPass``) or as
|
||||
little as a single transformation. The index values may also be nested so that
|
||||
if an invocation of the pass is not skipped individual transformations within
|
||||
that invocation may still be skipped.
|
||||
@ -99,7 +99,7 @@ is not a problem.
|
||||
When an opt-bisect index value refers to an entire invocation of the run
|
||||
function for a pass, the pass will query whether or not it should be skipped
|
||||
each time it is invoked and each invocation will be assigned a unique value.
|
||||
For example, if a FunctionPass is used with a module containing three functions
|
||||
For example, if a ``FunctionPass`` is used with a module containing three functions
|
||||
a different index value will be assigned to the pass for each of the functions
|
||||
as the pass is run. The pass may be run on two functions but skipped for the
|
||||
third.
|
||||
@ -144,13 +144,13 @@ Example Usage
|
||||
Pass Skipping Implementation
|
||||
============================
|
||||
|
||||
The -opt-bisect-limit implementation depends on individual passes opting in to
|
||||
the opt-bisect process. The OptBisect object that manages the process is
|
||||
The ``-opt-bisect-limit`` implementation depends on individual passes opting in to
|
||||
the opt-bisect process. The ``OptBisect`` object that manages the process is
|
||||
entirely passive and has no knowledge of how any pass is implemented. When a
|
||||
pass is run if the pass may be skipped, it should call the OptBisect object to
|
||||
pass is run if the pass may be skipped, it should call the ``OptBisect`` object to
|
||||
see if it should be skipped.
|
||||
|
||||
The OptBisect object is intended to be accessed through LLVMContext and each
|
||||
The ``OptBisect`` object is intended to be accessed through ``LLVMContext`` and each
|
||||
Pass base class contains a helper function that abstracts the details in order
|
||||
to make this check uniform across all passes. These helper functions are:
|
||||
|
||||
@ -160,7 +160,7 @@ to make this check uniform across all passes. These helper functions are:
|
||||
bool FunctionPass::skipFunction(const Function &F);
|
||||
bool LoopPass::skipLoop(const Loop *L);
|
||||
|
||||
A MachineFunctionPass should use FunctionPass::skipFunction() as such:
|
||||
A ``MachineFunctionPass`` should use ``FunctionPass::skipFunction()`` as such:
|
||||
|
||||
.. code-block:: c++
|
||||
|
||||
@ -170,11 +170,11 @@ A MachineFunctionPass should use FunctionPass::skipFunction() as such:
|
||||
// Otherwise, run the pass normally.
|
||||
}
|
||||
|
||||
In addition to checking with the OptBisect class to see if the pass should be
|
||||
skipped, the skipFunction(), skipLoop() and skipBasicBlock() helper functions
|
||||
also look for the presence of the "optnone" function attribute. The calling
|
||||
In addition to checking with the ``OptBisect`` class to see if the pass should be
|
||||
skipped, the ``skipFunction()``, ``skipLoop()`` and ``skipBasicBlock()`` helper functions
|
||||
also look for the presence of the ``optnone`` function attribute. The calling
|
||||
pass will be unable to determine whether it is being skipped because the
|
||||
"optnone" attribute is present or because the opt-bisect-limit has been
|
||||
``optnone`` attribute is present or because the ``opt-bisect-limit`` has been
|
||||
reached. This is desirable because the behavior should be the same in either
|
||||
case.
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user