<ol>
<li>you really, really, really can't use the binaries we distribute</li>
- <li>you need GCC to fix some of the header files on your system</li>
<li>you are an elite GCC hacker.</li>
</ol>
<!--=========================================================================-->
<div class="doc_text">
-<p>If you are building LLVM and the C front-end under Cygwin, please note that
+<p>If you are building LLVM and the GCC front-end under Cygwin, please note that
the LLVM and GCC makefiles do not correctly handle spaces in paths. To deal
with this issue, make sure that your LLVM and GCC source and build trees are
located in a top-level directory (like <tt>/cygdrive/c/llvm</tt> and
<!--=========================================================================-->
<div class="doc_text">
-<p>If you are building LLVM and the C front-end under AIX, do NOT use GNU
+<p>If you are building LLVM and the GCC front-end under AIX, do NOT use GNU
Binutils. They are not stable under AIX and may produce incorrect and/or
invalid code. Instead, use the system assembler and linker.
</p>
</pre></li>
-<li><p>Configure, build, and install the C front-end:</p>
+<li><p>Configure, build, and install the GCC front-end:</p>
<p>
<b>Linux/x86:</b><br>
<ul>
<li><p><b>Fix 1:</b> If you have system header files that include
inline assembly, you may have to modify them to remove the inline
- assembly, and install the modified versions in
+ assembly and install the modified versions in
<code>$CFEINSTALL/lib/gcc/<i>target-triplet</i>/3.4-llvm/include</code>.</li>
<li><b>Fix 2:</b> If you are building the C++ front-end on a CPU we
and apply a patch so that it does not use inline assembly.</li>
</ul>
- <p><b>Porting to a new architecture:</b> If you are porting the new front-end
- to a new architecture, or compiling in a different configuration that we have
- previously, there are probably several changes you will have to make to the GCC
- target to get it to work correctly. These include:<p>
+ <p><b>Porting to a new architecture:</b> If you are porting the front-end
+ to a new architecture or compiling in a configuration that we have
+ not tried previously, there are probably several changes you will have to make
+ t
o the GCC target to get it to work correctly. These include:<p>
<ul>
<li>Often targets include special assembler or linker flags which
<li><p>Go back into the LLVM source tree proper. Rerun configure, using
the <code>--with-llvmgccdir=$CFEINSTALL</code> option to specify the path
-to the newly built C front-end.</p></li>
+to the newly built GCC front-end.</p></li>
<li><p>If you edited header files during the C/C++ front-end build as
described in "Fix 1" above, you must now copy those header files from
<li><p>Rebuild your CVS tree. This shouldn't cause the whole thing to be
rebuilt, but it should build the runtime libraries. After the tree is
- built, install the runtime libraries into your C front-end build tree.
+ built, install the runtime libraries into your GCC front-end build tree.
These are the commands you need.</p>
<pre>
% gmake
following means:</p>
<ul>
<li> compiling and running a "hello, LLVM" program in C and C++.</li>
- <li> running the tests under <tt>test/Programs</tt> using <code>gmake -C
- test/Programs</code></li>
+ <li> running the regression tests in <tt>llvm/test</tt>
+ <li> running the tests found in the <tt>llvm-test</tt> CVS module</li>
</ul></li>
</ol>
</div>
files. However, it cannot be used to write them. While the B<llvm-ar> command
produces files that are I<almost> identical to the format used by other C<ar>
implementations, it has two significant departures in order to make the
-archive appropriate for LLVM. There are first departure is that B<llvm-ar> only
+archive appropriate for LLVM. The first departure is that B<llvm-ar> only
uses BSD4.4 style long path names (stored immediately after the header) and
never contains a string table for long names. The second departure is that the
symbol table is formated for efficient construction of an in-memory data
B<llvm-ar> can compress the members of an archive to save space. The
compression used depends on what's available on the platform and what choices
the LLVM Compressor utility makes. It generally favors bzip2 but will select
-between "no compression", bzip2 or zlib depending on what makes sense for the
+between "no compression" or bzip2 depending on what makes sense for the
file's content.
=item I<Directory Recursion>
=item [z]
When inserting or replacing any file in the archive, compress the file first.
-The compression will attempt to use the zlib compression algorithm. This
+This
modifier is safe to use when (previously) compressed bytecode files are added to
-the archive; the compress bytecode files will not be doubly compressed.
+the archive; the compressed bytecode files will not be doubly compressed.
=back
string. If the size field is negative (starts with a minus sign, 0x02D), then
the archive member is stored in compressed form. The first byte of the archive
member's data indicates the compression type used. A value of 0 (0x30) indicates
-that no compression was used. A value of 1 (0x31) indicates that zlib
-compression was used. A value of 2 (0x32) indicates that bzip2 compression was
-used.
+that no compression was used. A value of 2 (0x32) indicates that bzip2
+compression was used.
=item fmag - char[2]
<ol>
<li><tt>cd <i>where-you-want-the-C-front-end-to-live</i></tt>
<li><tt>gunzip --stdout cfrontend.<i>platform</i>.tar.gz | tar -xvf -</tt>
- <li><b>Sparc and MacOS X Only:</b><br>
- <tt>cd cfrontend/<i>platform</i><br>
+ <li><tt>cd cfrontend/<i>platform</i><br>
./fixheaders</tt>
</ol></li>
<ol>
<li><tt>cd <i>where-you-want-llvm-to-live</i></tt>
<li><tt>gunzip --stdout llvm-<i>version</i>.tar.gz | tar -xvf -</tt>
- <li><tt>cd llvm</tt>
+ <li><tt>cd llvm</tt></li>
</ol></li>
<li>With anonymous CVS access (or use a <a href="#mirror">mirror</a>):
</ol></li>
</ul></li>
+ <li>Get the Test Suite Source Code (<em>optional</em>)
+ <ul>
+ <li>With the distributed files:
+ <ol>
+ <li><tt>cd <i>where-you-want-llvm-to-live</i></tt>
+ <li><tt>cd llvm/projects</tt>
+ <li><tt>gunzip --stdout llvm-test-<i>version</i>.tar.gz | tar -xvf -</tt>
+ <li><tt>cd ..</tt></li>
+ </ol></li>
+
+ <li>With anonymous CVS access (or use a <a href="#mirror">mirror</a>):
+ <ol>
+ <li><tt>cd <i>where-you-want-llvm-to-live</i></tt></li>
+ <li><tt>cd llvm/projects</tt>
+ <li><tt>cvs -d
+ :pserver:anon@llvm-cvs.cs.uiuc.edu:/var/cvs/llvm login</tt></li>
+ <li>Hit the return key when prompted for the password.
+ <li><tt>cvs -z3 -d :pserver:anon@llvm-cvs.cs.uiuc.edu:/var/cvs/llvm
+ co llvm-test</tt></li>
+ <li><tt>cd llvm-test</tt></li>
+ <li><tt>cvs up -P -d</tt></li>
+ <li><tt>cd ..</tt></li>
+ </ol></li>
+ </ul></li>
+
+
<li>Configure the LLVM Build Environment
<ol>
<li>Change directory to where you want to store the LLVM object
<p>
If you have the LLVM distribution, you will need to unpack it before you
can begin to compile it. LLVM is distributed as a set of two files: the LLVM
-suite and the LLVM GCC front end compiled for your platform. Each
-file is a TAR archive that is compressed with the gzip program.
+suite and the LLVM GCC front end compiled for your platform. There is an
+additional test suite that is optional. Each file is a TAR archive that is
+compressed with the gzip program.
</p>
<p> The files are as follows:
<dt><tt>cfrontend-1.4.i386-unknown-freebsd5.1.tar.gz</tt></dt>
<dd>This is the binary release of the GCC front end for FreeBSD/x86.<br/></dd>
- <dt><tt>cfrontend-1.4.powerpc-apple-darwin7.0.0.tar.gz</tt></dt>
+ <dt><tt>cfrontend-1.4.powerpc-apple-darwin7.6.0.tar.gz</tt></dt>
<dd>This is the binary release of the GCC front end for MacOS X/PPC.<br/></dd>
</dl>
-</tt></li>
</ol>
-<p>If you are using Solaris/Sparc or MacOS X/PPC, you will need to fix the
-header files:</p>
+<p>Next, you will need to fix your system header files:</p>
<p><tt>cd cfrontend/<i>platform</i><br>
./fixheaders</tt></p>
<dt><b>Null pointer constants</b></dt>
- <dd>The identifier '<tt>null</tt>' is recognized as a null pointer constant,
+ <dd>The identifier '<tt>null</tt>' is recognized as a null pointer constant
and must be of <a href="#t_pointer">pointer type</a>.</dd>
</dl>
-<p>The one non-intuitive notation for constants is the optional hexidecimal form
+<p>The one non-intuitive notation for constants is the optional hexadecimal form
of floating point constants. For example, the form '<tt>double
0x432ff973cafa8000</tt>' is equivalent to (but harder to read than) '<tt>double
4.5e+15</tt>'. The only time hexadecimal floating point constants are required
<dd>Structure constants are represented with notation similar to structure
type definitions (a comma separated list of elements, surrounded by braces
- (<tt>{}</tt>). For example: "<tt>{ int 4, float 17.0 }</tt>". Structure
+ (<tt>{}</tt>)). For example: "<tt>{ int 4, float 17.0 }</tt>". Structure
constants must have <a href="#t_struct">structure type</a>, and the number and
types of elements must match those specified by the type.
</dd>
<dd>Array constants are represented with notation similar to array type
definitions (a comma separated list of elements, surrounded by square brackets
- (<tt>[]</tt>). For example: "<tt>[ int 42, int 11, int 74 ]</tt>". Array
+ (<tt>[]</tt>)). For example: "<tt>[ int 42, int 11, int 74 ]</tt>". Array
constants must have <a href="#t_array">array type</a>, and the number and
types of elements must match those specified by the type.
</dd>
<dd>Packed constants are represented with notation similar to packed type
definitions (a comma separated list of elements, surrounded by
- less-than/greater-than's (<tt><></tt>). For example: "<tt>< int 42,
+ less-than/greater-than's (<tt><></tt>)). For example: "<tt>< int 42,
int 11, int 74, int 100 ></tt>". Packed constants must have <a
href="#t_packed">packed type</a>, and the number and types of elements must
match those specified by the type.
<p>The addresses of <a href="#globalvars">global variables</a> and <a
href="#functionstructure">functions</a> are always implicitly valid (link-time)
-constants. These constants explicitly referenced when the <a
-href="#identifiers">identifier for the global</a> is used
, and always have <a
+constants. These constants
are explicitly referenced when the <a
+href="#identifiers">identifier for the global</a> is used and always have <a
href="#t_pointer">pointer</a> type. For example, the following is a legal LLVM
file:</p>
finished. These terminator instructions typically yield a '<tt>void</tt>'
value: they produce control flow, not values (the one exception being
the '<a href="#i_invoke"><tt>invoke</tt></a>' instruction).</p>
-
-<p>There are five different terminator instructions: the '<a
+<p>There are six different terminator instructions: the '<a
href="#i_ret"><tt>ret</tt></a>' instruction, the '<a href="#i_br"><tt>br</tt></a>'
instruction, the '<a href="#i_switch"><tt>switch</tt></a>' instruction,
the '<a href="#i_invoke"><tt>invoke</tt></a>' instruction, the '<a
<div class="doc_text">
<p>Binary operators are used to do most of the computation in a
program. They require two operands, execute an operation on them, and
-produce a single value. Although, that single value might represent
+produce a single value. The operands might represent
multiple data, as is the case with the <a href="#t_packed">packed</a> data type.
The result value of a binary operator is not
necessarily the same type as its operands.</p>
<div class="doc_text">
<p>Bitwise binary operators are used to do various forms of
bit-twiddling in a program. They are generally very efficient
-instructions, and can commonly be strength reduced from other
+instructions and can commonly be strength reduced from other
instructions. They require two operands, execute an operation on them,
and produce a single value. The resulting value of the bitwise binary
operators is always the same type as its first operand.</p>
<p>A key design point of an SSA-based representation is how it
represents memory. In LLVM, no memory locations are in SSA form, which
makes things very simple. This section describes how to read, write,
-allocate and free memory in LLVM.</p>
+allocate, and free memory in LLVM.</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection"> <a name="i_malloc">'<tt>malloc</tt>'
that was allocated with the '<tt><a href="#i_malloc">malloc</a></tt>'
instruction.</p>
<h5>Semantics:</h5>
-<p>Access to the memory pointed to by the pointer is not longer defined
+<p>Access to the memory pointed to by the pointer is no longer defined
after this instruction executes.</p>
<h5>Example:</h5>
<pre> %array = <a href="#i_malloc">malloc</a> [4 x ubyte] <i>; yields {[4 x ubyte]*}:array</i>
stack frame of the procedure that is live until the current function
returns to its caller.</p>
<h5>Arguments:</h5>
-<p>The the '<tt>alloca</tt>' instruction allocates <tt>sizeof(<type>)*NumElements</tt>
+<p>The '<tt>alloca</tt>' instruction allocates <tt>sizeof(<type>)*NumElements</tt>
bytes of memory on the runtime stack, returning a pointer of the
appropriate type to the program. The second form of the instruction is
a shorter version of the first that defaults to allocating one element.</p>
<h5>Overview:</h5>
-<p>The '<tt>llvm.gcroot</tt>' intrinsic declares the existance of a GC root to
+<p>The '<tt>llvm.gcroot</tt>' intrinsic declares the existence of a GC root to
the code generator, and allows some metadata to be associated with it.</p>
<h5>Arguments:</h5>
<p>
<li>
- The LLVM source tree provides benchmarks and programs which are
- known to compile with the LLVM GCC front ends. You can use these
+ LLVM contains an optional package called <tt>llvm-test</tt>
+ which provides benchmarks and programs that are known to compile with the
+ LLVM GCC front ends. You can use these
programs to test your code, gather statistics information, and
- compare it to the current LLVM performance statistics. These
- programs are found in the <tt>llvm/test/Programs</tt> directory.
+ compare it to the current LLVM performance statistics.
<p>
Currently, there is no way to hook your tests directly into the
- <tt>llvm/test/Programs</tt> testing harness. You will simply
+ <tt>llvm/test</tt> testing harness. You will simply
need to find a way to use the source provided within that directory
on your own.
</ul>
programs in C and C++ is in the <tt>llvm-test</tt> module. This module should
be checked out to the <tt>llvm/projects</tt> directory. When you
<tt>configure</tt> the <tt>llvm</tt> module, the <tt>llvm-test</tt> module
-will be automatically configured. Or you can do it manually.</p>
+will be automatically configured. Alternatively, you can configure the <tt>llvm-test</tt> module manually.</p>
<p>To run all of the simple tests in LLVM using DejaGNU, use the master Makefile in the
<tt>llvm/test</tt> directory:</p>
<pre>
<p>The LLVM test suite contains two major categories of tests: code
fragments and whole programs. Code fragments are in the <tt>llvm</tt> module
under the directory under the <tt>llvm/test</tt> directory. The whole programs
-test suite are n the <tt>llvm-test</tt> module under the main directory.</p>
+test suite are in the <tt>llvm-test</tt> module under the main directory.</p>
</div>
<div class="doc_text">
<p>The LLVM test suite is partially driven by DejaGNU and partially
driven by GNU Make. Specifically, the Features and Regression tests
-are all driven by DejaGNU. The llvm-test
+are all driven by DejaGNU. The <tt>llvm-test</tt>
module is currently driven by a set of Makefiles.</p>
<p>The DejaGNU structure is very simple, but does require some
-information to be set. This information is gathered via configure and
-is written to a file, <tt>site.exp</tt> in llvm/test. The llvm/test
+information to be set. This information is gathered via <tt>configure</tt> and
+is written to a file, <tt>site.exp</tt> in <tt>llvm/test</tt>. The
+<tt>llvm/test</tt>
Makefile does this work for you.</p>
<p>In order for DejaGNU to work, each directory of tests must have a
tests. By default, it will run all of these tests.</p>
<p>To run only the DejaGNU driven tests, run <tt>gmake</tt> at the
-command line in llvm/tests. To run a specific directory of tests, specify the TESTSUITE.
+command line in llvm/tests. To run a specific directory of tests, use the
+TESTSUITE variable.
</p>
<p>For example, to run the Regression tests, type
manual for the LLVM command line utilities ("man" pages for LLVM tools).<br/>
Current tools:
<a href="CommandGuide/html/llvm-ar.html">llvm-ar</a>,
+ <a href="CommandGuide/html/llvm-ranlib.html">llvm-ranlib</a>,
<a href="CommandGuide/html/llvm-as.html">llvm-as</a>,
<a href="CommandGuide/html/llvm-dis.html">llvm-dis</a>,
<a href="CommandGuide/html/opt.html">opt</a>,
projects / oota-llvm.git / commitdiff