mirror of
https://github.com/RPCS3/llvm.git
synced 2024-11-26 13:10:42 +00:00
Merged in RELEASE_14 changes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@18763 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
John Criswell
parent
5aefa8a6fe
commit
9e2485c122
@ -45,7 +45,6 @@ process, and you should <b>only</b> try to do it if:</p>
|
||||
|
||||
<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>
|
||||
|
||||
@ -59,7 +58,7 @@ process, and you should <b>only</b> try to do it if:</p>
|
||||
<!--=========================================================================-->
|
||||
|
||||
<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
|
||||
@ -76,7 +75,7 @@ and Settings" directory). We welcome patches to fix this issue.
|
||||
<!--=========================================================================-->
|
||||
|
||||
<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>
|
||||
@ -121,7 +120,7 @@ invalid code. Instead, use the system assembler and linker.
|
||||
</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>
|
||||
@ -176,7 +175,7 @@ functions from C as referenced from C++, so we typically configure with
|
||||
<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
|
||||
@ -186,10 +185,10 @@ functions from C as referenced from C++, so we typically configure with
|
||||
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
|
||||
to the GCC target to get it to work correctly. These include:<p>
|
||||
|
||||
<ul>
|
||||
<li>Often targets include special assembler or linker flags which
|
||||
@ -216,7 +215,7 @@ functions from C as referenced from C++, so we typically configure with
|
||||
|
||||
<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
|
||||
@ -228,7 +227,7 @@ libgcc.a library, which you can find by running
|
||||
|
||||
<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
|
||||
@ -255,8 +254,8 @@ the <tt>llvm-ranlib</tt> tool to do this, as follows:</p>
|
||||
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>
|
||||
|
||||
@ -23,7 +23,7 @@ The B<llvm-ar> command can be used to I<read> both SVR4 and BSD style archive
|
||||
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
|
||||
@ -63,7 +63,7 @@ slash (/) character.
|
||||
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>
|
||||
@ -229,9 +229,9 @@ a time stamp than the time stamp of the member in the archive.
|
||||
=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
|
||||
|
||||
@ -342,9 +342,8 @@ This field provides the size of the file, in bytes, encoded as a decimal ASCII
|
||||
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]
|
||||
|
||||
|
||||
@ -115,8 +115,7 @@ and performance.
|
||||
<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>
|
||||
|
||||
@ -126,7 +125,7 @@ and performance.
|
||||
<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>):
|
||||
@ -142,6 +141,32 @@ and performance.
|
||||
</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
|
||||
@ -548,8 +573,9 @@ You can set these on the command line, or better yet, set them in your
|
||||
<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:
|
||||
@ -573,7 +599,7 @@ file is a TAR archive that is compressed with the gzip program.
|
||||
<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>
|
||||
|
||||
@ -672,8 +698,7 @@ location must be specified when the LLVM suite is configured.</p>
|
||||
-</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>
|
||||
|
||||
@ -806,12 +806,12 @@ them all and their syntax.</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
|
||||
@ -834,7 +834,7 @@ assembly and disassembly do not cause any bits to change in the constants.</p>
|
||||
|
||||
<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>
|
||||
@ -843,7 +843,7 @@ assembly and disassembly do not cause any bits to change in the constants.</p>
|
||||
|
||||
<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>
|
||||
@ -852,7 +852,7 @@ assembly and disassembly do not cause any bits to change in the constants.</p>
|
||||
|
||||
<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.
|
||||
@ -879,8 +879,8 @@ assembly and disassembly do not cause any bits to change in the constants.</p>
|
||||
|
||||
<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>
|
||||
|
||||
@ -964,8 +964,7 @@ indicates which block should be executed after the current block is
|
||||
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
|
||||
@ -1200,7 +1199,7 @@ no-return function cannot be reached, and other facts.</p>
|
||||
<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>
|
||||
@ -1378,7 +1377,7 @@ Operations</a> </div>
|
||||
<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>
|
||||
@ -1603,7 +1602,7 @@ Operations</a></div>
|
||||
<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>'
|
||||
@ -1651,7 +1650,7 @@ memory heap, to be reallocated in the future.</p>
|
||||
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>
|
||||
@ -1671,7 +1670,7 @@ Instruction</a> </div>
|
||||
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>
|
||||
@ -2304,7 +2303,7 @@ href="GarbageCollection.html">Accurate Garbage Collection with LLVM</a>.
|
||||
|
||||
<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>
|
||||
|
||||
@ -201,14 +201,14 @@ directories:</p>
|
||||
<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>
|
||||
|
||||
@ -102,7 +102,7 @@ regression tests are in the main "llvm" module under the directory
|
||||
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>
|
||||
@ -140,7 +140,7 @@ programs), run the <tt>llvm-test</tt> tests:</p>
|
||||
<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>
|
||||
|
||||
@ -251,12 +251,13 @@ location of these external programs is configured by the llvm-test
|
||||
<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
|
||||
@ -392,7 +393,8 @@ test suite creates temporary files during execution.</p>
|
||||
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
|
||||
|
||||
@ -55,6 +55,7 @@ some tools.</li>
|
||||
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>,
|
||||
|
||||
Loading…
Reference in New Issue
Block a user