mirror of
https://github.com/c64scene-ar/llvm-6502.git
synced 2024-12-13 04:30:23 +00:00
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:
parent
66a72ef15a
commit
693464c57a
@ -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 <plugin>
|
||||
<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 <plugin> -help</tt>' to see the new
|
||||
list of available analysis passes.
|
||||
<p>
|
||||
|
||||
<li> -profile-info-file <filename>
|
||||
<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>
|
||||
|
@ -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 <program arguments>...</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 ..... |& 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 <library></tt><br>
|
||||
Load <tt><library></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 <program args></tt><br>
|
||||
Pass all arguments specified after <tt>-args</tt> to the
|
||||
test program whenever it runs. Note that if any of
|
||||
the <tt><program args></tt> start with a '-', you should use:
|
||||
<p>
|
||||
<tt>bugpoint <bugpoint args> -args -- <program args></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 <tool args></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 <bugpoint args> -tool-args -- <tool args></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 <filename></tt><br>
|
||||
Open <tt><filename></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 <plugin></tt><br>
|
||||
Load the dynamic object <tt><plugin></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 <plugin> -help</tt>
|
||||
<p>
|
||||
|
||||
<a name="opt_output"><li><tt>-output <filename></tt><br>
|
||||
Whenever the test program produces output on its standard output
|
||||
stream, it should match the contents of <tt><filename></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 <filename></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>
|
@ -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 <function>
|
||||
<br>
|
||||
Extract the specified function from the LLVM bytecode.
|
||||
<p>
|
||||
|
||||
<li> -help
|
||||
<br>
|
||||
Print a summary of command line options.
|
||||
<p>
|
||||
|
||||
<li> -o <filename>
|
||||
<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>
|
||||
|
@ -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] < filename></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 <filename>
|
||||
<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>
|
||||
|
@ -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] < filename> [ 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<library>.bc, lib<library>.a, or
|
||||
lib<library>.<shared library extension>, 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 <filename>
|
||||
<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=<directory>
|
||||
<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 <filename>
|
||||
<br>
|
||||
Preserve the list of symbol names in the file filename.
|
||||
<p>
|
||||
|
||||
<li> -internalize-public-api-list <list>
|
||||
<br>
|
||||
Preserve the symbol names in list.
|
||||
<p>
|
||||
|
||||
<li> -l=<library>
|
||||
<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<library>.bc, lib<library>.a, and
|
||||
lib<library>.<shared library extension>, 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>
|
||||
|
@ -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<arch>
|
||||
<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 <filename>
|
||||
<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=<ra>
|
||||
<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=<sp>
|
||||
<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>
|
||||
|
@ -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=<arch></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=<name></tt>
|
||||
<br>
|
||||
Call the function named <tt><name></tt> to start the program.
|
||||
Note: The function is assumed to have the C signature <tt>int
|
||||
<tt><name></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>
|
@ -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 <filename>
|
||||
<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>
|
||||
|
@ -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>
|
@ -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 <filename>
|
||||
<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>
|
||||
|
@ -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] <filename> [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 <directory>
|
||||
<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 <filename>
|
||||
<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>
|
||||
|
@ -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>
|
||||
|
@ -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>
|
@ -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>
|
||||
|
@ -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>
|
||||
|
@ -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 <filename>
|
||||
<br>
|
||||
Specify the output filename.
|
||||
<p>
|
||||
|
||||
<li> -profile-info-file <filename>
|
||||
<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 <plugin>
|
||||
<br>
|
||||
Load the dynamic object <plugin>. 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 <plugin> -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>
|
||||
|
Loading…
Reference in New Issue
Block a user