The HTML documentation is now automatically generated from POD source.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@14578 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
Misha Brukman 2004-07-02 15:48:33 +00:00
parent 66a72ef15a
commit 693464c57a
16 changed files with 0 additions and 1859 deletions

View File

@ -1,86 +0,0 @@
<html>
<title>
LLVM: analyze tool
</title>
<body bgcolor=white>
<center><h1>LLVM: <tt>analyze</tt> tool</h1></center>
<HR>
<h3>NAME</h3>
<tt>analyze</tt>
<h3>SYNOPSIS</h3>
<tt>analyze [options] [filename]</tt>
<h3>DESCRIPTION</h3>
The <tt>analyze</tt> command performs various analysis of LLVM assembly code or
bytecode. It will usually print the results on standard output, but in a few
cases, it will print output to standard error or generate a file with the
analysis output (which is usually done when the output is meant for another
program).
<p>
If filename is omitted or is -, <tt>analyze</tt> reads its input from standard
input. It first attempts to interpret its input as LLVM bytecode. If it
encounters an error, it then attempts to parse the input as LLVM assembly
language.
<h3>OPTIONS</h3>
<ul>
<li> -help
<br>
Print a summary of command line options.
<p>
<li> -q
<br>
Quiet mode. With this option, analysis pass names are not printed.
<p>
<li> -load &lt;plugin&gt;
<br>
Load the specified dynamic object with name <tt>plugin</tt>. This file
should contain additional analysis passes that register themselves with
the <tt>analyze</tt> program after being loaded.
<p>
After being loaded, additional command line options are made available
for running the passes made available by <tt>plugin</tt>. Use
'<tt><tt>analyze</tt> -load &lt;plugin&gt; -help</tt>' to see the new
list of available analysis passes.
<p>
<li> -profile-info-file &lt;filename&gt;
<br>
Specify the name of the file loaded by the -profile-loader option.
<p>
<li> -stats
<br>
Print statistics.
<p>
<li> -time-passes
<br>
Record the amount of time needed for each pass and print it to standard
error.
<p>
</ul>
<h3>EXIT STATUS</h3>
If <tt>analyze</tt> succeeds, it will exit with 0. Otherwise, if an error
occurs, it will exit with a non-zero value.
<h3>SEE ALSO</h3>
<a href="opt.html"><tt>opt</tt></a>
<HR>
Maintained by the <a href="http://llvm.cs.uiuc.edu">LLVM Team</a>.
</body>
</html>

View File

@ -1,249 +0,0 @@
<html>
<title>LLVM: bugpoint tool</title>
<body bgcolor=white>
<center><h1>LLVM: <tt>bugpoint</tt> tool</h1></center>
<HR>
<h3>NAME</h3>
<tt>bugpoint</tt>
<h3>SYNOPSIS</h3>
<tt>bugpoint [options] [input LLVM ll/bc files] [LLVM passes] --args &lt;program arguments&gt;...</tt>
<img src="../img/Debugging.gif" width=444 height=314 align=right>
<h3>DESCRIPTION</h3>
The <tt>bugpoint</tt> tool narrows down the source of
problems in LLVM tools and passes. It can be used to debug three types of
failures: optimizer crashes, miscompilations by optimizers, or bad native
code generation (including problems in the static and JIT compilers). It aims
to reduce large test cases to small, useful ones. For example,
if <tt><a href="gccas.html">gccas</a></tt> crashes while optimizing a file, it
will identify the optimization (or combination of optimizations) that causes the
crash, and reduce the file down to a small example which triggers the crash.<p>
<a name="designphilosophy">
<h4>Design Philosophy</h4>
<tt>bugpoint</tt> is designed to be a useful tool without requiring any
hooks into the LLVM infrastructure at all. It works with any and all LLVM
passes and code generators, and does not need to "know" how they work. Because
of this, it may appear to do stupid things or miss obvious
simplifications. <tt>bugpoint</tt> is also designed to trade off programmer
time for computer time in the compiler-debugging process; consequently, it may
take a long period of (unattended) time to reduce a test case, but we feel it
is still worth it. Note that <tt>bugpoint</tt> is generally very quick unless
debugging a miscompilation where each test of the program (which requires
executing it) takes a long time.<p>
<a name="automaticdebuggerselection">
<h4>Automatic Debugger Selection</h4>
<tt>bugpoint</tt> reads each <tt>.bc</tt> or <tt>.ll</tt> file
specified on the command line and links them together into a single module,
called the test program. If any LLVM passes are
specified on the command line, it runs these passes on the test program. If
any of the passes crash, or if they produce malformed output (which causes the
verifier to abort),
<tt>bugpoint</tt> starts the <a href="#crashdebug">crash debugger</a>.<p>
Otherwise, if the <a href="#opt_output"><tt>-output</tt></a> option was not
specified, <tt>bugpoint</tt> runs the test program with the C backend (which is
assumed to generate good code) to generate a reference output. Once
<tt>bugpoint</tt> has a reference output for the test program, it tries
executing it with the <a href="#opt_run-">selected</a> code generator. If the
selected code generator crashes, <tt>bugpoint</tt> starts the <a
href="#crashdebug">crash debugger</a> on the code generator. Otherwise, if the
resulting output differs from the reference output, it assumes the difference
resulted from a code generator failure, and starts the <a
href="#codegendebug">code generator debugger</a>.<p>
Finally, if the output of the selected code generator matches the reference
output, <tt>bugpoint</tt> runs the test program after all of the LLVM passes
have been applied to it. If its output differs from the reference output, it
assumes the difference resulted from a failure in one of the LLVM passes, and
enters the <a href="#miscompilationdebug">miscompilation
debugger</a>. Otherwise, there is no problem <tt>bugpoint</tt> can debug.<p>
<a name="crashdebug">
<h4>Crash debugger</h4>
If an optimizer or code generator crashes, <tt>bugpoint</tt> will try as hard as
it can to reduce the list of passes (for optimizer crashes) and the size of the
test program. First, <tt>bugpoint</tt> figures out which combination of
optimizer passes triggers the bug. This is useful when debugging a problem
exposed by <tt>gccas</tt>, for example, because it runs over 38 passes.<p>
Next, <tt>bugpoint</tt> tries removing functions from the test program, to
reduce its size. Usually it is able to reduce a test program to a single
function, when debugging intraprocedural optimizations. Once the number of
functions has been reduced, it attempts to delete various edges in the control
flow graph, to reduce the size of the function as much as possible. Finally,
<tt>bugpoint</tt> deletes any individual LLVM instructions whose absence does
not eliminate the failure. At the end, <tt>bugpoint</tt> should tell you what
passes crash, give you a bytecode file, and give you instructions on how to
reproduce the failure with <tt><a href="opt.html">opt</a></tt>, <tt><a
href="analyze.html">analyze</a></tt>, or <tt><a href="llc.html">llc</a></tt>.<p>
<a name="codegendebug">
<h4>Code generator debugger</h4>
<p>The code generator debugger attempts to narrow down the amount of code that
is being miscompiled by the <a href="#opt_run-">selected</a> code generator. To
do this, it takes the test program and partitions it into two pieces: one piece
which it compiles with the C backend (into a shared object), and one piece which
it runs with either the JIT or the static LLC compiler. It uses several
techniques to reduce the amount of code pushed through the LLVM code generator,
to reduce the potential scope of the problem. After it is finished, it emits
two bytecode files (called "test" [to be compiled with the code generator] and
"safe" [to be compiled with the C backend], respectively), and instructions for
reproducing the problem. The code generator debugger assumes that the C backend
produces good code.</p>
<a name="miscompilationdebug">
<h4>Miscompilation debugger</h4>
The miscompilation debugger works similarly to the code generator
debugger. It works by splitting the test program into two pieces, running the
optimizations specified on one piece, linking the two pieces back together,
and then executing the result.
It attempts to narrow down the list of passes to the one (or few) which are
causing the miscompilation, then reduce the portion of the test program which is
being miscompiled. The miscompilation debugger assumes that the selected
code generator is working properly.<p>
<a name="bugpoint notes">
<h4>Advice for using <tt>bugpoint</tt></h4>
<tt>bugpoint</tt> can be a remarkably useful tool, but it sometimes works in
non-obvious ways. Here are some hints and tips:<p>
<ol>
<li>In the code generator and miscompilation debuggers, <tt>bugpoint</tt> only
works with programs that have deterministic output. Thus, if the program
outputs <tt>argv[0]</tt>, the date, time, or any other "random" data, <tt>bugpoint</tt> may
misinterpret differences in these data, when output, as the result of a
miscompilation. Programs should be temporarily modified to disable
outputs that are likely to vary from run to run.
<li>In the code generator and miscompilation debuggers, debugging will go
faster if you manually modify the program or its inputs to reduce the
runtime, but still exhibit the problem.
<li><tt>bugpoint</tt> is extremely useful when working on a new optimization:
it helps track down regressions quickly. To avoid having to relink
<tt>bugpoint</tt> every time you change your optimization however, have
<tt>bugpoint</tt> dynamically load your optimization with the <a
href="#opt_load"><tt>-load</tt></a> option.
<li><tt>bugpoint</tt> can generate a lot of output and run for a long period of
time. It is often useful to capture the output of the program to file. For
example, in the C shell, you can type:<br>
<tt>bugpoint ..... |&amp; tee bugpoint.log</tt>
<br>to get a copy of <tt>bugpoint</tt>'s output in the file
<tt>bugpoint.log</tt>, as well as on your terminal.
<li><tt>bugpoint</tt> cannot debug problems with the LLVM linker. If
<tt>bugpoint</tt> crashes before you see its "All input ok" message,
you might try <tt>llvm-link -v</tt> on the same set of input files. If
that also crashes, you may be experiencing a linker bug.
<li>If your program is <b>supposed</b> to crash, <tt>bugpoint</tt> will be
confused. One way to deal with this is to cause bugpoint to ignore the exit
code from your program, by giving it the <tt>-check-exit-code=false</tt>
option.
</ol>
<h3>OPTIONS</h3>
<ul>
<li><tt>-additional-so &lt;library&gt;</tt><br>
Load <tt>&lt;library&gt;</tt> into the test program whenever it is run.
This is useful if you are debugging programs which depend on non-LLVM
libraries (such as the X or curses libraries) to run.<p>
<li><tt>-args &lt;program args&gt;</tt><br>
Pass all arguments specified after <tt>-args</tt> to the
test program whenever it runs. Note that if any of
the <tt>&lt;program args&gt;</tt> start with a '-', you should use:
<p>
<tt>bugpoint &lt;bugpoint args&gt; -args -- &lt;program args&gt;</tt>
<p>
The "<tt>--</tt>" right after the <tt>-args</tt> option tells
<tt>bugpoint</tt> to consider any options starting with <tt>-</tt> to be
part of the <tt>-args</tt> option, not as options to <tt>bugpoint</tt>
itself.<p>
<li><tt>-tool-args &lt;tool args&gt;</tt><br>
Pass all arguments specified after <tt>-tool-args</tt> to the
LLVM tool under test (llc, lli, etc.) whenever it runs.
You should use this option in the following way:
<p>
<tt>bugpoint &lt;bugpoint args&gt; -tool-args -- &lt;tool args&gt;</tt>
<p>
The "<tt>--</tt>" right after the <tt>-tool-args</tt> option tells
<tt>bugpoint</tt> to consider any options starting with <tt>-</tt> to be
part of the <tt>-tool-args</tt> option, not as options to
<tt>bugpoint</tt> itself. (See <tt>-args</tt>, above.)<p>
<li><tt>-check-exit-code={true,false}</tt><br>
Assume a non-zero exit code or core dump from the test program is
a failure. Defaults to true.<p>
<li><tt>-disable-{dce,simplifycfg}</tt><br>
Do not run the specified passes to clean up and reduce the size of the
test program. By default, <tt>bugpoint</tt> uses these passes internally
when attempting to reduce test programs. If you're trying to find
a bug in one of these passes, <tt>bugpoint</tt> may crash.<p>
<li> <tt>-help</tt><br>
Print a summary of command line options.<p>
<a name="opt_input"><li><tt>-input &lt;filename&gt;</tt><br>
Open <tt>&lt;filename&gt;</tt> and redirect the standard input of the
test program, whenever it runs, to come from that file.
<p>
<a name="opt_load"><li> <tt>-load &lt;plugin&gt;</tt><br>
Load the dynamic object <tt>&lt;plugin&gt;</tt> into <tt>bugpoint</tt>
itself. This object should register new
optimization passes. Once loaded, the object will add new command line
options to enable various optimizations. To see the new complete list
of optimizations, use the -help and -load options together:
<p>
<tt>bugpoint -load &lt;plugin&gt; -help</tt>
<p>
<a name="opt_output"><li><tt>-output &lt;filename&gt;</tt><br>
Whenever the test program produces output on its standard output
stream, it should match the contents of <tt>&lt;filename&gt;</tt>
(the "reference output"). If you do not use this option,
<tt>bugpoint</tt> will attempt to generate a reference output by
compiling the program with the C backend and running it.<p>
<li><tt>-profile-info-file &lt;filename&gt;</tt><br>
Profile file loaded by -profile-loader.<p>
<a name="opt_run-"><li><tt>-run-{int,jit,llc,cbe}</tt><br>
Whenever the test program is compiled, <tt>bugpoint</tt> should generate
code for it using the specified code generator. These options allow
you to choose the interpreter, the JIT compiler, the static native
code compiler, or the C backend, respectively.<p>
</ul>
<h3>EXIT STATUS</h3>
If <tt>bugpoint</tt> succeeds in finding a problem, it will exit with 0.
Otherwise, if an error occurs, it will exit with a non-zero value.
<h3>SEE ALSO</h3>
<a href="opt.html"><tt>opt</tt></a>,
<a href="analyze.html"><tt>analyze</tt></a>
<HR>
Maintained by the <a href="http://llvm.cs.uiuc.edu">LLVM Team</a>.
</body>
</html>

View File

@ -1,93 +0,0 @@
<html>
<title>
LLVM: extract tool
</title>
<body bgcolor=white>
<center>
<h1>LLVM: <tt>extract</tt> tool</h1>
</center>
<HR>
<h3>NAME</h3>
<tt>extract</tt>
<h3>
SYNOPSIS
</h3>
<tt>extract [options] [filename]</tt>
<h3>
DESCRIPTION
</h3>
The <tt>extract</tt> command takes the name of a function and extracts it from
the specified LLVM bytecode file. It is primarily used as a debugging tool to
reduce test cases from larger programs that are triggering a bug.
<p>
In addition to extracting the bytecode of the specified function,
<tt>extract</tt> will also remove unreachable global variables, prototypes, and
unused types.
<p>
The <tt>extract</tt> command reads its input from standard input if filename is
omitted or if filename is -. The output is always written to standard output.
<h3>OPTIONS</h3>
<ul>
<ul>
<li> -f
<br>
Force overwrite. Normally, <tt>extract</tt> will refuse to overwrite an
output file that already exists. With this option, <tt>extract</tt>
will overwrite the output file and replace it with new bytecode.
<p>
<li>-func &lt;function&gt;
<br>
Extract the specified function from the LLVM bytecode.
<p>
<li> -help
<br>
Print a summary of command line options.
<p>
<li> -o &lt;filename&gt;
<br>
Specify the output filename. If filename is "-" (the default), then
<tt>extract</tt> sends its output to standard output.
<p>
<li> -stats
<br>
Print statistics.
<p>
<li> -time-passes
<br>
Record the amount of time needed for each pass and print it to standard
error.
<p>
</ul>
<h3>
EXIT STATUS
</h3>
If <tt>extract</tt> succeeds, it will exit with 0. Otherwise, if an error
occurs, it will exit with a non-zero value.
<h3>
SEE ALSO
</h3>
<a href="bugpoint.html"><tt>bugpoint</tt></a>
<HR>
Maintained by the <a href="http://llvm.cs.uiuc.edu">LLVM Team</a>.
</body>
</html>

View File

@ -1,84 +0,0 @@
<html>
<title>LLVM: gccas tool</title>
<body bgcolor=white>
<center>
<h1>LLVM: <tt>gccas</tt> tool</h1>
</center>
<HR>
<h3>NAME</h3>
<tt>gccas</tt>
<h3>SYNOPSIS</h3>
<tt>gccas [options] &lt; filename&gt;</tt>
<h3>DESCRIPTION</h3>
The <tt>gccas</tt> utility takes an LLVM assembly file generated by the <a
href="llvmgcc.html">C</a> or <a href="llvmgxx.html">C++</a> frontends and
converts it into an LLVM bytecode file. It is primarily used by the GCC front
end, and as such, attempts to mimic the interface provided by the default system
assembler so that it can act as a "drop-in" replacement.<p>
<tt>gccas</tt> performs a number of optimizations on the input program.<p>
<h3>
OPTIONS
</h3>
<ul>
<li> -help
<br>
Print a summary of command line options.
<p>
<li> -o &lt;filename&gt;
<br>
Specify the output filename which will hold the assembled bytecode.
<p>
<li>-disable-inlining
<br>
Disable the inlining pass. By default, it is enabled.
<p>
<li> -disable-opt
<br>
Disable all assemble-time optimization passes.
<p>
<li> -stats
<br>
Print statistics.
<p>
<li> -time-passes
<br>
Record the amount of time needed for each pass and print it to standard
error.
<p>
<li> -verify
<br>
Verify each pass result.
<p>
</ul>
<h3>
EXIT STATUS
</h3>
If <tt>gccas</tt> succeeds, it will exit with 0. Otherwise, if an error occurs,
it will exit with a non-zero value.
<h3>SEE ALSO</h3>
<a href="llvm-as.html"><tt>llvm-as</tt></a>
<a href="gccld.html"><tt>gccld</tt></a>
<HR>
Maintained by the <a href="http://llvm.cs.uiuc.edu">LLVM Team</a>.
</body>
</html>

View File

@ -1,210 +0,0 @@
<html>
<title>LLVM: gccld tool</title>
<body bgcolor=white>
<center><h1>LLVM: <tt>gccld</tt> tool</h1></center>
<HR>
<h3>NAME</h3>
<tt>gccld</tt>
<h3>SYNOPSIS</h3>
<tt>gccld [options] &lt; filename&gt; [ filename ...]</tt>
<h3>DESCRIPTION</h3>
The <tt>gccld</tt> utility takes a set of LLVM bytecode files and links them
together into a single LLVM bytecode file. The output bytecode file can be
another bytecode library or an executable bytecode program. Using additional
options, <tt>gccld</tt> is able to produce native code executables.
<p>
The <tt>gccld</tt> utility is primarily used by the <a href="llvmgcc.html">C</a>
and <a href="llvmgxx.html">C++</a> front-ends, and as such, attempts to mimic
the interface provided by the default system linker so that it can act as a
"drop-in" replacement.
<p>
The <tt>gccld</tt> tool performs a small set of interprocedural, post-link,
optimizations on the program.
<h4>Search Order</h4>
<p>
When looking for objects specified on the command line, <tt>gccld</tt> will
search for the object first in the current directory and then in the directory
specified by the <tt>LLVM_LIB_SEARCH_PATH</tt> environment variable. If it
cannot find the object, it fails.
</p>
<p>
When looking for a library specified with the -l option, <tt>gccld</tt> first
attempts to load a file with that name from the current directory. If that
fails, it looks for lib&lt;library&gt;.bc, lib&lt;library&gt;.a, or
lib&lt;library&gt;.&lt;shared library extension&gt;, in that order, in each
directory added to the library search path with the -L option. These
directories are searched in the order they
were specified. If the library cannot be located, then <tt>gccld</tt> looks in
the directory specified by the <tt>LLVM_LIB_SEARCH_PATH</tt> environment
variable. If it does not find a library there, it fails.
</p>
<p>
The shared library extension is usually <tt>.so</tt>, but it may differ
depending upon the system.
</p>
<p>
The -L option is global. It does not matter where it is specified in the list
of command line arguments; the directory is simply added to the search path and
is applied to all libraries, preceding or succeeding, in the command line.
</p>
<h4>Link order</h4>
All object files are linked first in the order they were specified on the
command line. All library files are linked next. Some libraries may not be
linked into the object program; see below.
<h4>Library Linkage</h4>
Object files and static bytecode objects are always linked into the output
file. Library archives (.a files) load only the objects within the archive
that define symbols needed by the output file. Hence, libraries should be
listed after the object files and libraries which need them; otherwise, the
library may not be linked in, and the dependent library will not have its
undefined symbols defined.
<h4>Native code generation</h4>
The <tt>gccld</tt> program has limited support for native code generation, when
using the <tt>-native</tt> or <tt>-native-cbe</tt> options.
<h3>OPTIONS</h3>
<ul>
<li> -help
<br>
Print a summary of command line options.
<p>
<li> -o &lt;filename&gt;
<br>
Specify the output filename which will hold the linked bytecode.
<p>
<li> -stats
<br>
Print statistics.
<p>
<li> -time-passes
<br>
Record the amount of time needed for each pass and print it to standard
error.
<p>
<li> -verify
<br>
Verify each pass result.
<p>
<li> -disable-opt
<br>
Disable all link-time optimization passes.
<p>
<li> -disable-inlining
<br>
Do not run the inliner pass.
<p>
<li> -L=&lt;directory&gt;
<br>
Add directory to the list of directories to search when looking for
libraries.
<p>
<li> -disable-internalize
<br>
Do not mark all symbols as internal.
<p>
<li> -internalize-public-api-file &lt;filename&gt;
<br>
Preserve the list of symbol names in the file filename.
<p>
<li> -internalize-public-api-list &lt;list&gt;
<br>
Preserve the symbol names in list.
<p>
<li> -l=&lt;library&gt;
<br>
Specify libraries to include when linking the output file. When
linking, <tt>gccld</tt> will first attempt to load a file with the
pathname <tt>library</tt>. If that fails, it will then attempt to load
lib&lt;library&gt;.bc, lib&lt;library&gt;.a, and
lib&lt;library&gt;.&lt;shared library extension&gt;, in that order.
<p>
<li> -link-as-library
<br>
Link the .bc files together as a library, not an executable.
<p>
<li> -native
<br>
Generate a native, machine code executable.
<p>
When generating native executables, <tt>gccld</tt> first checks for a bytecode
version of the library and links it in, if necessary. If the library is
missing, <tt>gccld</tt> skips it. Then, <tt>gccld</tt> links in the same
libraries as native code.
<p>
In this way, <tt>gccld</tt> should be able to link in optimized bytecode
subsets of common libraries and then link in any part of the library that
hasn't been converted to bytecode.
<p>
<li> -native-cbe
<br>
Generate a native, machine code executable with the LLVM C backend.
<p>
This option is identical to the <tt>-native</tt> option, but uses the
C backend to generate code for the program instead of an LLVM native
code generator.
</p>
<li> -s
<br>
Strip symbol information from the generated executable.
<p>
<li> -v
<br>
Print information about actions taken.
</ul>
<h3>EXIT STATUS</h3>
If <tt>gccld</tt> succeeds, it will exit with 0. Otherwise, if an error occurs,
it will exit with a non-zero value.
<h3>SEE ALSO</h3>
<a href="llvm-link.html"><tt>llvm-link</tt></a>
<a href="gccas.html"><tt>gccas</tt></a>
<h3>BUGS</h3>
The -L option cannot be used for find native code libraries when using the
-native option.
<HR>
Maintained by the <a href="http://llvm.cs.uiuc.edu">LLVM Team</a>.
</body>
</html>

View File

@ -1,220 +0,0 @@
<html>
<title>LLVM: llc tool</title>
<body bgcolor=white>
<center><h1>LLVM: <tt>llc</tt> tool</h1></center>
<HR>
<h3>NAME</h3>
<tt>llc</tt>
<h3>SYNOPSIS</h3>
<tt>llc [options] [filename]</tt>
<h3>DESCRIPTION</h3>
The <tt>llc</tt> command compiles LLVM bytecode into assembly language for a
specified architecture. The assembly language output can then be passed through
a native assembler and linker to generate native code.
<p>
The choice of architecture for the output assembly code is determined as
follows:
<ul>
<li>
If the user has specified an architecture with the -m option, use that
architecture.
<p>
<li>
Examine the input LLVM bytecode file:
<ul>
<li>
If it specifies little endian and a pointer size of 32 bits, select the
x86 architecture.
<p>
<li>
If it specifies big endian and a pointer size of 64 bit pointers,
select the SparcV9 architecture.
</ul>
<p>
<li>
If <tt>llc</tt> was compiled on an architecture for which it can
generate code, select the architecture upon which <tt>llc</tt> was
compiled.
<p>
<li>
Print a message to the user asking him or her to specify the output
architecture explicitly.
</ul>
<p>
If filename is not specified, or if filename is -, <tt>llc</tt> reads its input
from standard input. Otherwise, it will read its input from filename.
<p>
If the -o option is left unspecified, then <tt>llc</tt> will send its output to standard
output if the input is from standard input. If the -o option specifies -, then
the output will also be sent to standard output.
<p>
If no -o option is specified and an input file other than - is specified, then
<tt>llc</tt> creates the output filename as follows:
<ul>
<li>
If the file ends in .bc, then the .bc suffix is removed, and the .s suffix
is appended.
<p>
<li>
Otherwise, the .s suffix is appended to the input filename.
</ul>
<h3>
OPTIONS
</h3>
<ul>
<li>-f
<br>
Overwrite output files
<p>
<li>-m&lt;arch&gt;
<br>
Specify the architecture for which to generate assembly. Valid
architectures are:
<dl compact>
<dt> x86 </dt>
<dd>IA-32 (Pentium and above)</dd>
<dt> sparcv9 </dt>
<dd>SPARC V9</dd>
<dt> c </dt>
<dd>Emit C code</dd>
</dl>
<p>
<li>-o &lt;filename&gt;
<br>
Specify the output filename.
<p>
<li>-enable-correct-eh-support
<br>
Instruct the -lowerinvoke pass to insert code for correct exception handling
support. This is expensive and is by default omitted for efficiency.
<p>
<li> -help
<br>
Print a summary of command line options.
<p>
<li> -stats
<br>
Print statistics.
<p>
<li> -time-passes
<br>
Record the amount of time needed for each pass and print it to standard
error.
<p>
</ul>
<h4>X86 Specific Options</h4>
<ul>
<li>-disable-fp-elim
<br>
Disable frame pointer elimination optimization.
<p>
<li>-disable-pattern-isel
<br>
Use the 'simple' X86 instruction selector (the default).
<p>
<li>-print-machineinstrs
<br>
Print generated machine code.
<p>
<li>-regalloc=&lt;ra&gt;
<br>
Specify the register allocator to use. The default is <i>local</i>.
Valid register allocators are:
<p>
<dl compact>
<dt> simple </dt>
<dd>Very simple register allocator</dd>
<dt> local </dt>
<dd>Local register allocator</dd>
<dt> linearscan </dt>
<dd>Linear scan global register allocator (experimental)</dd>
</dl>
<li>-spiller=&lt;sp&gt;
<br>
Specify the spiller to use for register allocators that support it.
Currently this option is used by the linear scan register
allocator. The default is <i>local</i>.
Valid spillers are:
<p>
<dl compact>
<dt> simple </dt>
<dd>Simple spiller</dd>
<dt> local </dt>
<dd>Local spiller</dd>
</dl>
</ul>
<h4>Sparc Specific Options</h4>
<ul>
<li>-disable-peephole
<br>
Disable peephole optimization pass.
<p>
<li>-disable-sched
<br>
Disable local scheduling pass.
<p>
<li>-disable-strip
<br>
Do not strip the LLVM bytecode included in executable.
<p>
<li>-enable-maps
<br>
Emit LLVM-to-MachineCode mapping info to assembly.
<p>
</ul>
<h3>EXIT STATUS</h3>
If <tt>llc</tt> succeeds, it will exit with 0. Otherwise, if an error occurs,
it will exit with a non-zero value.
<h3>
SEE ALSO
</h3>
<a href="lli.html"><tt>lli</tt></a>
<HR>
Maintained by the <a href="http://llvm.cs.uiuc.edu">LLVM Team</a>.
</body>
</html>

View File

@ -1,107 +0,0 @@
<html>
<title>
LLVM: lli tool
</title>
<body bgcolor=white>
<center>
<h1>LLVM: <tt>lli</tt> tool</h1>
</center>
<HR>
<h3>
NAME
</h3>
<tt>lli</tt>
<h3>
SYNOPSIS
</h3>
<tt>lli [options] [filename] [args ...]</tt>
<h3>
DESCRIPTION
</h3>
<tt>lli</tt> directly executes programs in LLVM format.
It takes a program in LLVM
bytecode format and executes it using a just-in-time
compiler, if one is available for the current architecture, or an interpreter.
<tt>lli</tt> takes all of the same code generator options as the
<tt><a href="llc.html">llc</a></tt> tool, but they are only applicable when
the just-in-time compiler is being used.
<p>
If filename is not specified, then <tt>lli</tt> reads the LLVM bytecode for
the program from standard input.
<p>
The optional "args" specified on the command line are passed to the
program as arguments.
<p>
<h3>
OPTIONS
</h3>
<ul>
<li> <tt>-help</tt>
<br>
Print a summary of command line options.
<p>
<li> <tt>-stats</tt>
<br>
Print statistics from the code-generation passes. This is only meaningful
for the just-in-time compiler, at present.
<p>
<li> <tt>-time-passes</tt>
<br>
Record the amount of time needed for each code-generation pass and print
it to standard error.
<p>
<li> <tt>-march=&lt;arch&gt;</tt>
<br>
Use the specified non-default architecture when selecting a code generator
for the just-in-time compiler. This may result in a crash if you pick an
architecture which is not compatible with the hardware you are running
<tt>lli</tt> on.
<p>
<li> <tt>-force-interpreter={false,true}</tt>
<br>
If set to true, use the interpreter even if a just-in-time compiler is
available for this architecture. Defaults to false.
<p>
<li> <tt>-f=&lt;name&gt;</tt>
<br>
Call the function named <tt>&lt;name&gt;</tt> to start the program.
Note: The function is assumed to have the C signature <tt>int
<tt>&lt;name&gt;</tt> (int, char **, char **)</tt>.
If you try to use this option to call a function of incompatible type,
undefined behavior may result. Defaults to "main".
<p>
</ul>
<h3>
EXIT STATUS
</h3>
If <tt>lli</tt> fails to load the program, it will exit with an exit code of 1.
Otherwise, it will return the exit code of the program it executes.
<h3>
SEE ALSO
</h3>
<a href="llc.html"><tt>llc</tt></a>
<HR>
Maintained by the <a href="http://llvm.cs.uiuc.edu">LLVM Team</a>.
</body>
</html>

View File

@ -1,97 +0,0 @@
<html>
<title>
LLVM: llvm-as tool
</title>
<body bgcolor=white>
<center><h1>LLVM: <tt>llvm-as</tt> tool</h1></center>
<HR>
<h3>NAME</h3>
<tt>llvm-as</tt>
<h3>SYNOPSIS</h3>
<tt>llvm-as [options] [filename]</tt>
<h3>DESCRIPTION</h3>
The <tt>llvm-as</tt> command is the LLVM assembler. It reads a file containing
human readable LLVM assembly language, translates it to LLVM bytecode, and
writes the result into a file or to standard output.
<p>
If filename is omitted or is -, then <tt>llvm-as</tt> reads its input from
standard input.
<p>
If an output file is not specified with the <tt>-o</tt> option, then
<tt>llvm-as</tt> sends its output to a file or standard output by the following
logic:
<ul>
<li>
If the input is standard input, then the output is standard output.
<p>
<li>
If the input is a file that ends with .ll, then the output file is of
the same name, except that the suffix is changed to .bc.
<p>
<li>
If the input is a file that does not end with the .ll suffix, then the
output file has the same name as the input file, except that the .bc
suffix is appended.
<p>
</ul>
<h3>OPTIONS</h3>
<ul>
<li> -f
<br>
Force overwrite. Normally, <tt>llvm-as</tt> will refuse to overwrite an
output file that already exists. With this option, <tt>llvm-as</tt>
will overwrite the output file and replace it with new bytecode.
<p>
<li> -help
<br>
Print a summary of command line options.
<p>
<li> -o &lt;filename&gt;
<br>
Specify the output filename. If filename is -, then <tt>llvm-as</tt>
sends its output to standard output.
<p>
<li> -stats
<br>
Print statistics.
<p>
<li> -time-passes
<br>
Record the amount of time needed for each pass and print it to standard
error.
<p>
</ul>
<h3>EXIT STATUS</h3>
If <tt>llvm-as</tt> succeeds, it will exit with 0. Otherwise, if an error
occurs, it will exit with a non-zero value.
<h3>SEE ALSO</h3>
<a href="llvm-dis.html"><tt>llvm-dis</tt></a>
<a href="gccas.html"><tt>gccas</tt></a>
<HR>
Maintained by the <a href="http://llvm.cs.uiuc.edu">LLVM Team</a>.
</body>
</html>

View File

@ -1,26 +0,0 @@
<html>
<title>LLVM: llvm-db tool</title>
<body bgcolor=white>
<center><h1>LLVM: <tt>llvm-db</tt> tool</h1></center>
<HR>
<h3>NAME</h3>
<tt>llvm-db</tt>
<h3>SYNOPSIS</h3>
Details coming soon. Please see our <a href="../SourceLevelDebugging.html">Source Level Debugging document</a> in the meantime.
<h3>DESCRIPTION</h3>
<h3>OPTIONS</h3>
<h3>EXIT STATUS</h3>
<HR>
Maintained by the <a href="http://llvm.cs.uiuc.edu">LLVM Team</a>.
</body>
</html>

View File

@ -1,94 +0,0 @@
<html>
<title>
LLVM: llvm-dis tool
</title>
<body bgcolor=white>
<center><h1>LLVM: <tt>llvm-dis</tt> tool</h1></center>
<HR>
<h3>NAME</h3>
<tt>llvm-dis</tt>
<h3>SYNOPSIS</h3>
<tt>llvm-dis [options] [filename]</tt>
<h3>DESCRIPTION</h3>
The <tt>llvm-dis</tt> command is the LLVM disassembler. It takes an LLVM
bytecode file and converts it into LLVM assembly language or C source code with
equivalent functionality.
<p>
If filename is omitted, <tt>llvm-dis</tt> reads its input from standard input.
<p>
The default output file for <tt>llvm-dis</tt> is determined by the following logic:
<ul>
<li>
If the input is standard input or the file -, then the output is
standard output.
<p>
<li>
If the input filename ends in .bc, then the output filename will be
identical, except that the .bc suffix will be replaced by the .ll or .c
suffix (for LLVM assembly language and C code, respectively).
<p>
<li>
If the input filename does not end in .bc, then the output filename will
be identical to the input filename, except that the .ll or .c suffix
will be appended to the filename (for LLVM assembly language and C code,
respectively).
</ul>
<h3>OPTIONS</h3>
<ul>
<li> -llvm
<br>
Instruct <tt>llvm-dis</tt> to generate LLVM assembly code in human
readable format. This is the default behavior.
<p>
<li> -f
<br>
Force overwrite. Normally, <tt>llvm-dis</tt> will refuse to overwrite
an output file that already exists. With this option, <tt>llvm-dis</tt>
will overwrite the output file.
<p>
<li> -help
<br>
Print a summary of command line options.
<p>
<li> -o &lt;filename&gt;
<br>
Specify the output filename. If filename is -, then the output is sent
to standard output.
<p>
<li> -time-passes
<br>
Record the amount of time needed for each pass and print it to standard
error.
<p>
</ul>
<h3>EXIT STATUS</h3>
If <tt>llvm-dis</tt> succeeds, it will exit with 0. Otherwise, if an error
occurs, it will exit with a non-zero value.
<h3>SEE ALSO</h3>
<a href="llvm-as.html"><tt>llvm-as</tt></a>
<HR>
Maintained by the <a href="http://llvm.cs.uiuc.edu">LLVM Team</a>.
</body>
</html>

View File

@ -1,88 +0,0 @@
<html>
<title>
LLVM: llvm-link tool
</title>
<body bgcolor=white>
<center><h1>LLVM: <tt>llvm-link</tt> tool</h1></center>
<HR>
<h3>NAME</h3>
<tt>llvm-link</tt>
<h3>SYNOPSIS</h3>
<tt>llvm-link [options] &lt;filename&gt; [filename ...]</tt>
<h3>DESCRIPTION</h3>
The <tt>llvm-link</tt> command takes several LLVM bytecode files and links them
together into a single LLVM bytecode file. It writes the output file to
standard output, unless the -o option is used to specify a filename.
<p>
The <tt>llvm-link</tt> command attempts to load the input files from the current
directory. If that fails, it looks for each file in each of the
directories specified by the -L options on the command line. The library search
paths are global; each one is searched for every input file if necessary. The
directories are searched in the order they were specified on the command line.
<h3>
OPTIONS
</h3>
<ul>
<li>-L &lt;directory&gt;
<br>
Add the specified directory to the library search path. When looking
for libraries, <tt>llvm-link</tt> will look in pathname for libraries.
This option can be specified multiple times; <tt>llvm-link</tt> will
search inside these directories in the order in which they were
specified on the command line.
<p>
<li>-f
<br>
Overwrite output files. By default, <tt>llvm-link</tt> will not
overwrite an output file if it alreadys exists.
<p>
<li>-o &lt;filename&gt;
<br>
Output filename. If filename is -, then <tt>llvm-link</tt> will write
its output to standard output.
<p>
<li>-d
<br>
If specified, <tt>llvm-link</tt> prints a human-readable version of the
output bytecode file to standard error.
<p>
<li>-help
<br>
Print a summary of command line options.
<p>
<li>-v
<br>
Verbose mode. Print information about what <tt>llvm-link</tt> is doing.
This typically includes a message for each bytecode file linked in
and for each library found.
</ul>
<h3>
EXIT STATUS
</h3>
If <tt>llvm-link</tt> succeeds, it will exit with 0. Otherwise, if an error
occurs, it will exit with a non-zero value.
<h3>SEE ALSO</h3>
<a href="gccld.html"><tt>gccld</tt></a>
<HR>
Maintained by the <a href="http://llvm.cs.uiuc.edu">LLVM Team</a>.
</body>
</html>

View File

@ -1,118 +0,0 @@
<html>
<title>
LLVM: llvm-nm tool
</title>
<body bgcolor=white>
<center><h1>LLVM: <tt>llvm-nm</tt> tool</h1></center>
<HR>
<h3>NAME</h3>
<tt>llvm-nm</tt>
<h3>SYNOPSIS</h3>
<tt>llvm-nm [options] [filenames...]</tt>
<h3>DESCRIPTION</h3>
<p>The <tt>llvm-nm</tt> utility lists the names of symbols from the
LLVM bytecode files, or <tt>ar(1)</tt> archives containing LLVM
bytecode files, named on the command line. Each symbol is listed along
with some simple information about its provenance. If no filename is specified,
or - is used as a filename, <tt>llvm-nm</tt> will process a bytecode file
on its standard input stream.</p>
<p><tt>llvm-nm</tt>'s default output format is the traditional BSD
<tt>nm(1)</tt> output format. Each such output record consists of an
(optional) 8-digit hexadecimal address, followed by a type code
character, followed by a name, for each symbol. One record is printed
per line; fields are separated by spaces. When the address is omitted,
it is replaced by 8 spaces.</p>
<p>Type code characters currently supported, and their meanings, are
as follows:</p>
<table border>
<tr><td>U</td><td>Named object is referenced but undefined in this
bytecode file</td></tr>
<tr><td>C</td><td>Common (multiple defs link together into one
def)</td></tr>
<tr><td>W</td><td>Weak reference (multiple defs link together into zero or
one defs)</td></tr>
<tr><td>t</td><td>Local function (text) object</td></tr>
<tr><td>T</td><td>Global function (text) object</td></tr>
<tr><td>d</td><td>Local data object</td></tr>
<tr><td>D</td><td>Global data object</td></tr>
<tr><td>?</td><td>Something unrecognizable</td></tr>
</table>
<p>Because LLVM bytecode files typically contain objects that are not
considered to have addresses until they are linked into an executable
image or dynamically compiled "just-in-time", <tt>llvm-nm</tt> does
not print an address for any symbol, even symbols which are defined in
the bytecode file.</p>
<h3>OPTIONS</h3>
<ul>
<li> -P
<br>
Use POSIX.2 output format. Alias for --format=posix.
<p>
<li> -B (default)
<br>
Use BSD output format. Alias for --format=bsd.
<p>
<li> -help
<br>
Print a summary of command-line options and their meanings.
<p>
<li> -defined-only
<br>
Print only symbols defined in this bytecode file (as opposed
to symbols which may be referenced by objects in this file,
but not defined in this file.)
<p>
<li> -extern-only, -g
<br>
Print only symbols whose definitions are external; that is,
accessible from other bytecode files.
<p>
<li> -undefined-only, -u
<br>
Print only symbols referenced but not defined in this bytecode
file.
<p>
<li> -format=<i>fmt</i>, -f
<br>
Select an output format; <i>fmt</i> may be sysv, posix, or
bsd. The default is bsd.
<p>
</ul>
<h3>BUGS</h3>
<tt>llvm-nm</tt> cannot demangle C++ mangled
names, like GNU <tt>nm(1)</tt> can.
<h3>EXIT STATUS</h3>
<tt>llvm-nm</tt> exits with an exit code of zero.
<h3>SEE ALSO</h3>
<a href="llvm-dis.html"><tt>llvm-dis</tt></a>,
<tt>ar(1)</tt>,
<tt>nm(1)</tt>
<HR>
Maintained by the <a href="http://llvm.cs.uiuc.edu">LLVM Team</a>.
</body>
</html>

View File

@ -1,58 +0,0 @@
<html>
<title>LLVM: llvm-prof tool</title>
<body bgcolor=white>
<center><h1>LLVM: <tt>llvm-prof</tt> tool</h1></center>
<HR>
<h3>NAME</h3>
<tt>llvm-prof</tt>
<h3>SYNOPSIS</h3>
<tt>llvm-prof [options] [bytecode file] [llvmprof.out]</tt>
<h3>DESCRIPTION</h3>
The <tt>llvm-prof</tt> tool reads in an '<tt>llvmprof.out</tt>' file (which can
optionally use a specific file with the third program argument), a bytecode file
for the program, and produces a human readable report, suitable for determining
where the program hotspots are.<p>
This program is often used in conjunction with the <tt>utils/profile.pl</tt>
script. This script automatically instruments a program, runs it with the JIT,
then runs <tt>llvm-prof</tt> to format a report. To get more information about
<tt>utils/profile.pl</tt>, execute it with the <tt>--help</tt> option.<p>
<h3>OPTIONS</h3>
<ul>
<li><tt>--annotated-llvm</tt> or <tt>-A</tt><br>
In addition to the normal report printed, print out the code for the
program, annotated with execution frequency information. This can be
particularly useful when trying to visualize how frequently basic blocks
are executed. This is most useful with basic block profiling
information or better.<p>
<li><tt>--print-all-code</tt><br>
Using this option enables the <tt>--annotated-llvm</tt> option, but it
prints the entire module, instead of just the most commonly executed
functions.<p>
<li><tt>-time-passes</tt><br>
Record the amount of time needed for each pass and print it to standard
error.
</ul>
<h3>EXIT STATUS</h3>
<tt>llvm-prof</tt> returns 1 if it cannot load the bytecode file or the profile
information. Otherwise, it exits with zero.
<HR>
Maintained by the <a href="http://llvm.cs.uiuc.edu">LLVM Team</a>.
</body>
</html>

View File

@ -1,113 +0,0 @@
<html>
<title>
LLVM: llvmgcc tool
</title>
<body bgcolor=white>
<center>
<h1>LLVM: <tt>llvmgcc</tt> tool</h1>
</center>
<HR>
<h3>NAME</h3>
<tt>llvmgcc</tt>
<h3>
SYNOPSIS
</h3>
<tt>llvmgcc [options] filename</tt>
<h3>
DESCRIPTION
</h3>
The <tt>llvmgcc</tt> command is the LLVM C front end. It is a modified version
of the <a href="http://gcc.gnu.org">GNU Compiler Collection</a> (GCC) that takes
C programs and compiles them into LLVM bytecode or assembly language, depending
upon the options.
<p>
Unless the <tt>-S</tt> option is specified, <tt>llvmgcc</tt> will use the
<a href="gccas.html"><tt>gccas</tt></a> program to perform some optimizations
and create an LLVM bytecode file. Unless the <tt>-c</tt> option is specified,
<tt>llvmgcc</tt> will also use the <a href="gccld.html"><tt>gccld</tt></a>
program to perform further optimizations and link the resulting bytecode
file(s) with support libraries to create an executable program.
<p>
Being derived from GCC, llvmgcc has many of GCC's features and accepts most of
GCC's options. It handles a number of GCC's extensions to the C programming
language.
<p>
Below you will find several commonly used options:
<h3>
OPTIONS
</h3>
<ul>
<li> -S
<br>
Do not generate an LLVM bytecode file. Rather, compile the source file
into an LLVM assembly language file.
<p>
<li> -c
<br>
Do not generate a linked bytecode executable. Rather, compile the source
file into an LLVM bytecode file. This bytecode file can then be linked
with other bytecode files later to generate a full LLVM executable.
<p>
<li> -o <i>filename</i>
<br>
Specify the output file to be <i>filename</i>.
<p>
<li> -I <i>directory</i>
<br>
Add a directory to the header file search path. This option can be
repeated.
<p>
<li> -L <i>directory</i>
<br>
Add <i>directory</i> to the library search path. This option can be
repeated.
<p>
<li> -l<i>name</i>
<br>
Link in the library lib<i>name</i>.[bc | a | so]. This library should
be a bytecode library.
<p>
<li>-Wl,<i>option</i>
<br>
Pass <i>option</i> to the linker program, <a
href="gccld.html"><tt>gccld</tt></a>.
<p>
</ul>
<h3>
EXIT STATUS
</h3>
If <tt>llvmgcc</tt> succeeds, it will exit with 0. Otherwise, if an error
occurs, it will exit with a non-zero value.
<h3>
SEE ALSO
</h3>
<A HREF="llvmgxx.html"><tt>llvmg++</tt></A>,
<A HREF="gccas.html"><tt>gccas</tt></A>,
<A HREF="gccld.html"><tt>gccld</tt></A>,
and the Info documentation for <tt>gcc</tt>.
<HR>
Maintained by the <a href="http://llvm.cs.uiuc.edu">LLVM Team</a>.
</body>
</html>

View File

@ -1,107 +0,0 @@
<html>
<title>
LLVM: llvmg++ tool
</title>
<body bgcolor=white>
<center>
<h1>LLVM: <tt>llvmg++</tt> tool</h1>
</center>
<HR>
<h3>NAME</h3>
<tt>llvmg++</tt>
<h3>SYNOPSIS</h3>
<tt>llvmg++ [options] filename</tt>
<h3>DESCRIPTION</h3>
The <tt>llvmg++</tt> command is the LLVM C++ front end. It is a modified
version of g++ that takes C++ programs and compiles them into LLVM bytecode or
assembly language, depending upon the options.
<p>
Unless the <tt>-S</tt> option is specified, <tt>llvmg++</tt> will use the
<a href="gccas.html"><tt>gccas</tt></a> program to perform some optimizations
and create an LLVM bytecode file. Unless the <tt>-c</tt> option is specified,
<tt>llvmg++</tt> will also use the <a href="gccld.html"><tt>gccld</tt></a>
program to perform further optimizations and link the resulting bytecode
file(s) with support libraries to create an executable program.
<p>
Being derived from the <a href="http://gcc.gnu.org">GNU Compiler Collection</a>,
<tt>llvmg++</tt> has many of g++'s features and accepts most of g++'s options.
It handles a number of g++'s extensions to the C++ programming language.
<p>
Below you will find several commonly used options:
<h3>
OPTIONS
</h3>
<ul>
<li> -S
<br>
Do not generate an LLVM bytecode file. Rather, compile the source file
into an LLVM assembly language file.
<p>
<li> -c
<br>
Do not generate a linked executable. Rather, compile the source file
into an LLVM bytecode file. This bytecode file can then be linked with
other bytecode files later on to generate a full LLVM executable.
<p>
<li> -o <i>filename</i>
<br>
Specify the output file to be <i>filename</i>.
<p>
<li> -I <i>directory</i>
<br>
Add a directory to the header file search path. This option can be
repeated.
<p>
<li> -L <i>directory</i>
<br>
Add <i>directory</i> to the library search path. This option can be
repeated.
<p>
<li> -l<i>name</i>
<br>
Link in the library lib<i>name</i>.[bc | a | so]. This library should
be a bytecode library.
<p>
<li>-Wl,<i>option</i>
<br>
Pass <i>option</i> to the linker (usually gccld).
<p>
</ul>
<h3>
EXIT STATUS
</h3>
If <tt>llvmg++</tt> succeeds, it will exit with 0. Otherwise, if an error
occurs, it will exit with a non-zero value.
<h3>
SEE ALSO
</h3>
<A HREF="llvmgcc.html"><tt>llvmgcc</tt></A>,
<A HREF="gccas.html"><tt>gccas</tt></A>,
<A HREF="gccld.html"><tt>gccld</tt></A>
<HR>
Maintained by the <a href="http://llvm.cs.uiuc.edu">LLVM Team</a>.
</body>
</html>

View File

@ -1,109 +0,0 @@
<html>
<title>LLVM: opt tool</title>
<body bgcolor=white>
<center><h1>LLVM: <tt>opt</tt> tool</h1></center>
<HR>
<h3>NAME</h3>
<tt>opt</tt>
<h3>SYNOPSIS</h3>
<tt>opt [options] [filename]</tt>
<h3>DESCRIPTION</h3>
The <tt>opt</tt> command is the modular LLVM optimizer. It takes LLVM bytecode
as input, runs the specified optimizations on it, and then outputs the optimized
LLVM bytecode.
<p>
The optimizations available via <tt>opt</tt> depend upon what libraries were
linked into it as well as any additional libraries that have been loaded with
the <tt>-load</tt> option. Use the <tt>-help</tt> option to determine what
optimizations you can use.
<p>
If no filename is specified on the command line, <tt>opt</tt> reads its input
from standard input.
<p>
If an output filename is not specified with the <tt>-o</tt> option, <tt>opt</tt>
writes its output to the standard output.
<h3>OPTIONS</h3>
<ul>
<li> -f
<br>
Force overwrite. Normally, <tt>opt</tt> will refuse to overwrite an
output file that already exists. With this option, <tt>opt</tt> will
overwrite the output file and replace it with new bytecode.
<p>
<li> -help
<br>
Print a summary of command line options.
<p>
<li> -o &lt;filename&gt;
<br>
Specify the output filename.
<p>
<li> -profile-info-file &lt;filename&gt;
<br>
Specify the name of the file loaded by the -profile-loader option.
<p>
<li> -stats
<br>
Print statistics.
<p>
<li> -time-passes
<br>
Record the amount of time needed for each pass and print it to standard
error.
<p>
<li> -debug
<br>
If this is a debug build, this option will enable debug printouts from
passes which use the <tt>DEBUG</tt> macro. See the <a
href="../ProgrammersManual.html#DEBUG">Programmer's Manual</a> for more
information.
<p>
<li> -load &lt;plugin&gt;
<br>
Load the dynamic object &lt;plugin&gt;. This object should register new
optimization passes. Once loaded, the object will add new command line
options to enable various optimizations. To see the new complete list
of optimizations, use the -help and -load options together:
<p>
<tt>opt -load &lt;plugin&gt; -help</tt>
<p>
<li> -p
<br>
Print module after each transformation.
<p>
</ul>
<h3>EXIT STATUS</h3>
If <tt>opt</tt> succeeds, it will exit with 0. Otherwise, if an error occurs,
it will exit with a non-zero value.
<h3>SEE ALSO</h3>
<a href="analyze.html"><tt>analyze</tt></a>
<HR>
Maintained by the <a href="http://llvm.cs.uiuc.edu">LLVM Team</a>.
</body>
</html>