Compare commits
20 Commits
llvmorg-2.
...
llvmorg-1.
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
3c357fb4b0 | ||
|
|
a0877e6620 | ||
|
|
da45ebd298 | ||
|
|
0dd5964f48 | ||
|
|
e70acef70b | ||
|
|
4bee8e0a3a | ||
|
|
8f7bf8914a | ||
|
|
b549680585 | ||
|
|
53ee4b83bb | ||
|
|
d5d184faac | ||
|
|
eea45bf361 | ||
|
|
be0de4d917 | ||
|
|
d102fe3a95 | ||
|
|
e7faf76bef | ||
|
|
6496cf1d2a | ||
|
|
84da4a6965 | ||
|
|
5da0c61395 | ||
|
|
8d76ed912c | ||
|
|
807a8cfe7a | ||
|
|
17d73082cb |
@@ -56,7 +56,7 @@ D: The `paths' pass
|
||||
N: Reid Spencer
|
||||
E: rspencer@x10sys.com
|
||||
W: http://extprosys.sourceforge.net/
|
||||
D: Complete 'llvm' namespacification, bug fixes and improvements
|
||||
D: Complete 'llvm' namespacification, Stacker, bug fixes, and improvements
|
||||
|
||||
N: Bill Wendling
|
||||
E: wendling@isanbard.org
|
||||
|
||||
@@ -15,7 +15,7 @@ dnl AC_OUTPUT
|
||||
dnl **************************************************************************
|
||||
dnl * Initialize
|
||||
dnl **************************************************************************
|
||||
AC_INIT([[[LLVM]]],[[[1.0]]],[llvmbugs@cs.uiuc.edu])
|
||||
AC_INIT([[[LLVM]]],[[[1.1]]],[llvmbugs@cs.uiuc.edu])
|
||||
|
||||
dnl Place all of the extra autoconf files into the config subdirectory
|
||||
AC_CONFIG_AUX_DIR([autoconf])
|
||||
|
||||
18
llvm/configure
vendored
18
llvm/configure
vendored
@@ -1,6 +1,6 @@
|
||||
#! /bin/sh
|
||||
# Guess values for system-dependent variables and create Makefiles.
|
||||
# Generated by GNU Autoconf 2.57 for [LLVM] [1.0].
|
||||
# Generated by GNU Autoconf 2.57 for [LLVM] [1.1].
|
||||
#
|
||||
# Report bugs to <llvmbugs@cs.uiuc.edu>.
|
||||
#
|
||||
@@ -422,8 +422,8 @@ SHELL=${CONFIG_SHELL-/bin/sh}
|
||||
# Identity of this package.
|
||||
PACKAGE_NAME='[LLVM]'
|
||||
PACKAGE_TARNAME='--llvm--'
|
||||
PACKAGE_VERSION='[1.0]'
|
||||
PACKAGE_STRING='[LLVM] [1.0]'
|
||||
PACKAGE_VERSION='[1.1]'
|
||||
PACKAGE_STRING='[LLVM] [1.1]'
|
||||
PACKAGE_BUGREPORT='llvmbugs@cs.uiuc.edu'
|
||||
|
||||
ac_subdirs_all="$ac_subdirs_all projects/${i}"
|
||||
@@ -954,7 +954,7 @@ if test "$ac_init_help" = "long"; then
|
||||
# Omit some internal or obsolete options to make the list less imposing.
|
||||
# This message is too long to be a string in the A/UX 3.1 sh.
|
||||
cat <<_ACEOF
|
||||
\`configure' configures [LLVM] [1.0] to adapt to many kinds of systems.
|
||||
\`configure' configures [LLVM] [1.1] to adapt to many kinds of systems.
|
||||
|
||||
Usage: $0 [OPTION]... [VAR=VALUE]...
|
||||
|
||||
@@ -1016,7 +1016,7 @@ fi
|
||||
|
||||
if test -n "$ac_init_help"; then
|
||||
case $ac_init_help in
|
||||
short | recursive ) echo "Configuration of [LLVM] [1.0]:";;
|
||||
short | recursive ) echo "Configuration of [LLVM] [1.1]:";;
|
||||
esac
|
||||
cat <<\_ACEOF
|
||||
|
||||
@@ -1131,7 +1131,7 @@ fi
|
||||
test -n "$ac_init_help" && exit 0
|
||||
if $ac_init_version; then
|
||||
cat <<\_ACEOF
|
||||
[LLVM] configure [1.0]
|
||||
[LLVM] configure [1.1]
|
||||
generated by GNU Autoconf 2.57
|
||||
|
||||
Copyright 1992, 1993, 1994, 1995, 1996, 1998, 1999, 2000, 2001, 2002
|
||||
@@ -1146,7 +1146,7 @@ cat >&5 <<_ACEOF
|
||||
This file contains any messages produced by compilers while
|
||||
running configure, to aid debugging if configure makes a mistake.
|
||||
|
||||
It was created by [LLVM] $as_me [1.0], which was
|
||||
It was created by [LLVM] $as_me [1.1], which was
|
||||
generated by GNU Autoconf 2.57. Invocation command line was
|
||||
|
||||
$ $0 $@
|
||||
@@ -23279,7 +23279,7 @@ _ASBOX
|
||||
} >&5
|
||||
cat >&5 <<_CSEOF
|
||||
|
||||
This file was extended by [LLVM] $as_me [1.0], which was
|
||||
This file was extended by [LLVM] $as_me [1.1], which was
|
||||
generated by GNU Autoconf 2.57. Invocation command line was
|
||||
|
||||
CONFIG_FILES = $CONFIG_FILES
|
||||
@@ -23342,7 +23342,7 @@ _ACEOF
|
||||
|
||||
cat >>$CONFIG_STATUS <<_ACEOF
|
||||
ac_cs_version="\\
|
||||
[LLVM] config.status [1.0]
|
||||
[LLVM] config.status [1.1]
|
||||
configured by $0, generated by GNU Autoconf 2.57,
|
||||
with options \\"`echo "$ac_configure_args" | sed 's/[\\""\`\$]/\\\\&/g'`\\"
|
||||
|
||||
|
||||
@@ -14,6 +14,7 @@
|
||||
<ol>
|
||||
<li><a href="#cautionarynote">A Cautionary Note</a>
|
||||
<li><a href="#instructions">Instructions</a>
|
||||
<li><a href="#license">License Information</a>
|
||||
</ol>
|
||||
|
||||
<div class="doc_text">
|
||||
@@ -114,7 +115,23 @@ command line should like something like this:
|
||||
--enable-languages=c,c++ --host=sparcv9-sun-solaris2.8
|
||||
% gmake all-gcc
|
||||
% setenv LLVM_LIB_SEARCH_PATH `pwd`/gcc
|
||||
% gmake all; gmake install
|
||||
% gmake all
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
At this point, libstdc++ may fail to build because of wchar errors (look for
|
||||
errors that reference <tt>vfwscanf</tt> or <tt>wcstof</tt>). If that happens,
|
||||
edit <tt>sparcv9-sun-solaris2.8/libstdc++-v3/config.h</tt> and comment out the
|
||||
line that defines <tt>_GLIBCXX_USE_WCHAR_T</tt>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Then, continue as below:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
% gmake all
|
||||
% gmake install
|
||||
</pre>
|
||||
|
||||
<p><b>Common Problem:</b> You may get error messages regarding the fact
|
||||
@@ -196,6 +213,48 @@ following means:</p>
|
||||
</ol>
|
||||
</div>
|
||||
|
||||
<!-- *********************************************************************** -->
|
||||
<div class="doc_section">
|
||||
<a name="license">License Information</a>
|
||||
</div>
|
||||
|
||||
<div class="doc_text">
|
||||
<p>
|
||||
The LLVM GCC frontend is licensed to you under the GNU General Public License
|
||||
and the GNU Lesser General Public License. Please see the files COPYING and
|
||||
COPYING.LIB for more details.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The software also has the following additional copyrights:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
Copyright (c) 1994
|
||||
Hewlett-Packard Company
|
||||
|
||||
Permission to use, copy, modify, distribute and sell this software
|
||||
and its documentation for any purpose is hereby granted without fee,
|
||||
provided that the above copyright notice appear in all copies and
|
||||
that both that copyright notice and this permission notice appear
|
||||
in supporting documentation. Hewlett-Packard Company makes no
|
||||
representations about the suitability of this software for any
|
||||
purpose. It is provided "as is" without express or implied warranty.
|
||||
|
||||
Copyright (c) 1996, 1997, 1998, 1999
|
||||
Silicon Graphics Computer Systems, Inc.
|
||||
|
||||
Permission to use, copy, modify, distribute and sell this software
|
||||
and its documentation for any purpose is hereby granted without fee,
|
||||
provided that the above copyright notice appear in all copies and
|
||||
that both that copyright notice and this permission notice appear
|
||||
in supporting documentation. Silicon Graphics makes no
|
||||
representations about the suitability of this software for any
|
||||
purpose. It is provided "as is" without express or implied warranty.
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<!-- *********************************************************************** -->
|
||||
<!-- *********************************************************************** -->
|
||||
|
||||
<hr>
|
||||
|
||||
@@ -129,7 +129,8 @@ from the LLVM suite.</p>
|
||||
header files for the default platform. Useful options include:
|
||||
<ul>
|
||||
<li><tt>--with-llvmgccdir=<i>directory</i></tt>
|
||||
<p>Specify where the LLVM GCC frontend is installed.</p></li>
|
||||
<p>Specify the full pathname of where the LLVM GCC frontend is
|
||||
installed.</p></li>
|
||||
<li><tt>--enable-spec2000=<i>directory</i></tt>
|
||||
<p>Enable the SPEC2000 benchmarks for testing. The SPEC2000
|
||||
benchmarks should be available in
|
||||
@@ -181,24 +182,55 @@ software you will need.</p>
|
||||
|
||||
<li>Linux on x86 (Pentium and above)
|
||||
<ul>
|
||||
<li>Approximately 760 MB of Free Disk Space
|
||||
<li>Approximately 918 MB of Free Disk Space
|
||||
<ul>
|
||||
<li>Source code: 30 MB</li>
|
||||
<li>Object code: 670 MB</li>
|
||||
<li>GCC front end: 60 MB</li>
|
||||
<li>Source code: 28 MB</li>
|
||||
<li>Object code: 850 MB</li>
|
||||
<li>GCC front end: 40 MB</li>
|
||||
</ul></li>
|
||||
</ul></li>
|
||||
</ul>
|
||||
</li>
|
||||
|
||||
<p></p>
|
||||
|
||||
<li>Solaris on SparcV9 (Ultrasparc)
|
||||
<ul>
|
||||
<li>Approximately 1.24 GB of Free Disk Space
|
||||
<li>Approximately 1.52 GB of Free Disk Space
|
||||
<ul>
|
||||
<li>Source code: 30 MB</li>
|
||||
<li>Object code: 1000 MB</li>
|
||||
<li>GCC front end: 210 MB</li>
|
||||
<li>Source code: 28 MB</li>
|
||||
<li>Object code: 1470 MB</li>
|
||||
<li>GCC front end: 50 MB</li>
|
||||
</ul></li>
|
||||
</ul></li>
|
||||
</ul>
|
||||
</li>
|
||||
|
||||
<p></p>
|
||||
|
||||
<li>FreeBSD on x86 (Pentium and above)
|
||||
<ul>
|
||||
<li>Approximately 918 MB of Free Disk Space
|
||||
<ul>
|
||||
<li>Source code: 28 MB</li>
|
||||
<li>Object code: 850 MB</li>
|
||||
<li>GCC front end: 40 MB</li>
|
||||
</ul></li>
|
||||
</ul>
|
||||
</li>
|
||||
|
||||
<p></p>
|
||||
|
||||
<li>MacOS X on PowerPC
|
||||
<ul>
|
||||
<li>No native code generation
|
||||
<li>Approximately 1.20 GB of Free Disk Space
|
||||
<ul>
|
||||
<li>Source code: 28 MB</li>
|
||||
<li>Object code: 1160 MB</li>
|
||||
<li>GCC front end: 40 MB</li>
|
||||
</ul></li>
|
||||
</ul>
|
||||
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<p>The LLVM suite <i>may</i> compile on other platforms, but it is not
|
||||
@@ -252,7 +284,6 @@ LLVM:</p>
|
||||
|
||||
</ul>
|
||||
|
||||
|
||||
<p>The remainder of this guide is meant to get you up and running with
|
||||
LLVM and to give you some basic information about the LLVM environment.
|
||||
A <a href="#starting">complete guide to installation</a> is provided in the
|
||||
@@ -347,22 +378,31 @@ 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 three files. Each
|
||||
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.
|
||||
</p>
|
||||
|
||||
<p> The three files are as follows:
|
||||
<p> The files are as follows:
|
||||
<dl compact>
|
||||
<dt>llvm.tar.gz
|
||||
<dt>llvm-1.1.tar.gz
|
||||
<dd>This is the source code to the LLVM suite.
|
||||
<p>
|
||||
|
||||
<dt>cfrontend.sparc.tar.gz
|
||||
<dt>cfrontend-1.1.sparc-sun-solaris2.8.tar.gz
|
||||
<dd>This is the binary release of the GCC front end for Solaris/Sparc.
|
||||
<p>
|
||||
|
||||
<dt>cfrontend.x86.tar.gz
|
||||
<dt>cfrontend-1.1.i686-redhat-linux-gnu.tar.gz
|
||||
<dd>This is the binary release of the GCC front end for Linux/x86.
|
||||
<p>
|
||||
|
||||
<dt>cfrontend-1.1.i386-unknown-freebsd5.1.tar.gz
|
||||
<dd>This is the binary release of the GCC front end for FreeBSD/x86.
|
||||
<p>
|
||||
|
||||
<dt>cfrontend-1.1.powerpc-apple-darwin7.0.0.tar.gz
|
||||
<dd>This is the binary release of the GCC front end for MacOS X/PPC.
|
||||
</dl>
|
||||
|
||||
</div>
|
||||
@@ -390,6 +430,20 @@ follows:</p>
|
||||
directory and fully populate it with the LLVM source code, Makefiles,
|
||||
test directories, and local copies of documentation files.</p>
|
||||
|
||||
<p>
|
||||
If you want to get a specific release (as opposed to the most recent revision),
|
||||
you can specify a label. The following releases have the following label:
|
||||
<ul>
|
||||
<li>
|
||||
Release 1.1: <b>RELEASE_11</b>
|
||||
</li>
|
||||
|
||||
<li>
|
||||
Release 1.0: <b>RELEASE_1</b>
|
||||
</li>
|
||||
</ul>
|
||||
</p>
|
||||
|
||||
<p>Note that the GCC front end is not included in the CVS repository. You
|
||||
should have downloaded the binary distribution for your platform.</p>
|
||||
|
||||
@@ -411,12 +465,12 @@ location must be specified when the LLVM suite is configured.</p>
|
||||
|
||||
<ol>
|
||||
<li><tt>cd <i>where-you-want-the-front-end-to-live</i></tt></li>
|
||||
<li><tt>gunzip --stdout cfrontend.<i>platform</i>.tar.gz | tar -xvf
|
||||
<li><tt>gunzip --stdout cfrontend-<i>version</i>.<i>platform</i>.tar.gz | tar -xvf
|
||||
-</tt></li>
|
||||
</ol>
|
||||
|
||||
<p>If you are on a Sparc/Solaris machine, you will need to fix the header
|
||||
files:</p>
|
||||
<p>If you are using Solaris/Sparc or MacOS X/PPC, you will need to fix the
|
||||
header files:</p>
|
||||
|
||||
<p><tt>cd cfrontend/sparc<br>
|
||||
./fixheaders</tt></p>
|
||||
@@ -442,7 +496,8 @@ not for the faint of heart, so be forewarned.</p>
|
||||
<p>Once checked out from the CVS repository, the LLVM suite source code must be
|
||||
configured via the <tt>configure</tt> script. This script sets variables in
|
||||
<tt>llvm/Makefile.config</tt> and <tt>llvm/include/Config/config.h</tt>. It
|
||||
also populates <i>OBJ_ROOT</i> with the Makefiles needed to build LLVM.</p>
|
||||
also populates <i>OBJ_ROOT</i> with the Makefiles needed to begin building
|
||||
LLVM.</p>
|
||||
|
||||
<p>The following environment variables are used by the <tt>configure</tt>
|
||||
script to configure the build system:</p>
|
||||
@@ -476,7 +531,8 @@ script to configure the build system:</p>
|
||||
<dt><i>--with-llvmgccdir=LLVMGCCDIR</i>
|
||||
<dd>
|
||||
Path to the location where the LLVM C front end binaries and
|
||||
associated libraries will be installed.
|
||||
associated libraries were installed. This must be specified as an
|
||||
absolute pathname.
|
||||
<p>
|
||||
<dt><i>--enable-optimized</i>
|
||||
<dd>
|
||||
@@ -486,7 +542,8 @@ script to configure the build system:</p>
|
||||
<p>
|
||||
<dt><i>--enable-jit</i>
|
||||
<dd>
|
||||
Compile the Just In Time (JIT) functionality. This is not available
|
||||
Compile the Just In Time (JIT) compiler functionality. This is not
|
||||
available
|
||||
on all platforms. The default is dependent on platform, so it is best
|
||||
to explicitly enable it if you want it.
|
||||
<p>
|
||||
@@ -519,10 +576,10 @@ script to configure the build system:</p>
|
||||
<tt>LLVM_LIB_SEARCH_PATH</tt> environment variable in your startup scripts.
|
||||
This environment variable is used to locate "system" libraries like
|
||||
"<tt>-lc</tt>" and "<tt>-lm</tt>" when linking. This variable should be set to
|
||||
the absolute path for the bytecode-libs subdirectory of the GCC front end
|
||||
install, or <i>LLVMGCCDIR</i>/bytecode-libs. For example, one might set
|
||||
the absolute path of the <tt>bytecode-libs</tt> subdirectory of the GCC front
|
||||
end, or <i>LLVMGCCDIR</i>/<tt>bytecode-libs</tt>. For example, one might set
|
||||
<tt>LLVM_LIB_SEARCH_PATH</tt> to
|
||||
<tt>/home/vadve/lattner/local/x86/llvm-gcc/bytecode-libs</tt> for the X86
|
||||
<tt>/home/vadve/lattner/local/x86/llvm-gcc/bytecode-libs</tt> for the x86
|
||||
version of the GCC front end on our research machines.</p>
|
||||
|
||||
</div>
|
||||
|
||||
@@ -1,180 +0,0 @@
|
||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
|
||||
"http://www.w3.org/TR/html4/strict.dtd">
|
||||
<html>
|
||||
<head>
|
||||
<link rel="stylesheet" href="llvm.css" type="text/css">
|
||||
<title>LLVM vs. the World - Comparing Compilers to Compilers</title>
|
||||
</head>
|
||||
|
||||
<body>
|
||||
|
||||
<div class="doc_title">
|
||||
LLVM vs. the World - Comparing Compilers to Compilers
|
||||
</div>
|
||||
|
||||
<ol>
|
||||
<li><a href="#introduction">Introduction</a></li>
|
||||
<li><a href="#generalapplicability">General Applicability</a></li>
|
||||
<li><a href="#typesystem">Type System</a></li>
|
||||
<li><a href="#dataflowinformation">Control-flow and Data-flow Information</a></li>
|
||||
<li><a href="#registers">Registers</a></li>
|
||||
<li><a href="#programmerinterface">Programmer Interface</a></li>
|
||||
<li><a href="#codeemission">Machine Code Emission</a></li>
|
||||
</ol>
|
||||
|
||||
<div class="doc_text">
|
||||
<p><b>Written by Brian R. Gaeke</b></p>
|
||||
</div>
|
||||
|
||||
<!-- *********************************************************************** -->
|
||||
<div class="doc_section">
|
||||
<a name="introduction">Introduction</a>
|
||||
</div>
|
||||
<!-- *********************************************************************** -->
|
||||
|
||||
<div class="doc_text">
|
||||
<p>Whether you are a stranger to LLVM or not, and whether you are considering
|
||||
using it for your projects or not, you may find it useful to understand how we
|
||||
compare ourselves to other well-known compilers. The following list of points
|
||||
should help you understand -- from our point of view -- some of the important
|
||||
ways in which we see LLVM as different from other selected compilers and
|
||||
code generation systems.</p>
|
||||
|
||||
<p>At the moment, we only compare ourselves below to <a
|
||||
href="http://gcc.gnu.org/">GCC</a> and <a
|
||||
href="http://www.gnu.org/software/lightning/">GNU lightning</a>, but we will try
|
||||
to revise and expand it as our knowledge and experience permit. Contributions are
|
||||
welcome.</p>
|
||||
</div>
|
||||
|
||||
<!-- *********************************************************************** -->
|
||||
<div class="doc_section">
|
||||
<a name="generalapplicability">General Applicability</a>
|
||||
</div>
|
||||
<!-- *********************************************************************** -->
|
||||
|
||||
<div class="doc_text">
|
||||
<p>GNU lightning: Only currently usable for dynamic runtime emission of binary
|
||||
machine code to memory. Supports one backend at a time.</p>
|
||||
|
||||
<p>LLVM: Supports compilation of C and C++ (with more languages coming soon),
|
||||
strong SSA-based optimization at compile-time, link-time, run-time, and
|
||||
off-line, and multiple platform backends with Just-in-Time and ahead-of-time
|
||||
compilation frameworks. (See our tech report on <a
|
||||
href="http://llvm.cs.uiuc.edu/pubs/2003-09-30-LifelongOptimizationTR.html">Lifelong
|
||||
Code Optimization</a> for more.)</p>
|
||||
|
||||
<p>GCC: Many relatively mature platform backends support assembly-language code
|
||||
generation from many source languages. No run-time compilation
|
||||
support. Relatively weak optimization support.</p>
|
||||
</div>
|
||||
|
||||
<!-- *********************************************************************** -->
|
||||
<div class="doc_section">
|
||||
<a name="typesystem">Type System</a>
|
||||
</div>
|
||||
<!-- *********************************************************************** -->
|
||||
|
||||
<div class="doc_text">
|
||||
<p>GNU lightning: C integer types and "void *" are supported. No type checking
|
||||
is performed. Explicit type casts are not typically necessary unless the
|
||||
underlying machine-specific types are distinct (e.g., sign- or zero-extension is
|
||||
apparently necessary, but casting "int" to "void *" would not be.)
|
||||
Floating-point support may not work on all platforms (it does not appear to be
|
||||
documented in the latest release).</p>
|
||||
|
||||
<p>LLVM: Compositional type system based on C types, supporting structures,
|
||||
opaque types, and C integer and floating point types. Explicit cast instructions
|
||||
are required to transform a value from one type to another.</p>
|
||||
|
||||
<p>GCC: Union of high-level types including those used in Pascal, C, C++, Ada,
|
||||
Java, and FORTRAN.</p>
|
||||
</div>
|
||||
|
||||
<!-- *********************************************************************** -->
|
||||
<div class="doc_section">
|
||||
<a name="dataflowinformation">Control-flow and Data-flow Information</a>
|
||||
</div>
|
||||
<!-- *********************************************************************** -->
|
||||
|
||||
<div class="doc_text">
|
||||
<p>GNU lightning: No data-flow information encoded in the generated program. No
|
||||
support for calculating CFG or def-use chains over generated programs.</p>
|
||||
|
||||
<p>LLVM: Scalar values in Static Single-Assignment form; def-use chains and CFG
|
||||
always implicitly available and automatically kept up to date.</p>
|
||||
|
||||
<p>GCC: Trees and RTL do not directly encode data-flow info; but def-use chains
|
||||
and CFGs can be calculated on the side. They are not automatically kept up to
|
||||
date.</p>
|
||||
</div>
|
||||
|
||||
<!-- *********************************************************************** -->
|
||||
<div class="doc_section">
|
||||
<a name="registers">Registers</a>
|
||||
</div>
|
||||
<!-- *********************************************************************** -->
|
||||
|
||||
<div class="doc_text">
|
||||
<p>GNU lightning: Very small fixed register set -- it takes the least common
|
||||
denominator of supported platforms; basically it inherits its tiny register set
|
||||
from IA-32, unnecessarily crippling targets like PowerPC with a large register
|
||||
set.</p>
|
||||
|
||||
<p>LLVM: An infinite register set, reduced to a particular platform's finite
|
||||
register set by register allocator.</p>
|
||||
|
||||
<p>GCC: Trees and RTL provide an arbitrarily large set of values. Reduced to a
|
||||
particular platform's finite register set by register allocator.</p>
|
||||
</div>
|
||||
|
||||
<!-- *********************************************************************** -->
|
||||
<div class="doc_section">
|
||||
<a name="programmerinterface">Programmer Interface</a>
|
||||
</div>
|
||||
<!-- *********************************************************************** -->
|
||||
|
||||
<div class="doc_text">
|
||||
<p>GNU lightning: Library interface based on C preprocessor macros that emit
|
||||
binary code for a particular instruction to memory. No support for manipulating
|
||||
code before emission.</p>
|
||||
|
||||
<p>LLVM: Library interface based on classes representing platform-independent
|
||||
intermediate code (Instruction) and platform-dependent code (MachineInstr) which
|
||||
can be manipulated arbitrarily and then emitted to memory.</p>
|
||||
|
||||
<p>GCC: Internal header file interface (tree.h) to abstract syntax trees,
|
||||
representing roughly the union of all possible supported source-language
|
||||
constructs; also, an internal header file interface (rtl.h, rtl.def) to a
|
||||
low-level IR called RTL which represents roughly the union of all possible
|
||||
target machine instructions.</p>
|
||||
</div>
|
||||
|
||||
<!-- *********************************************************************** -->
|
||||
<div class="doc_section">
|
||||
<a name="codeemission">Machine Code Emission</a>
|
||||
</div>
|
||||
<!-- *********************************************************************** -->
|
||||
|
||||
<div class="doc_text">
|
||||
<p>GNU lightning: Only supports binary machine code emission to memory.</p>
|
||||
|
||||
<p>LLVM: Supports writing out assembly language to a file, and binary machine
|
||||
code to memory, from the same back-end.</p>
|
||||
|
||||
<p>GCC: Supports writing out assembly language to a file. No support for
|
||||
emitting machine code to memory.</p>
|
||||
</div>
|
||||
|
||||
<!-- *********************************************************************** -->
|
||||
|
||||
<hr>
|
||||
<div class="doc_footer">
|
||||
<address>Brian R. Gaeke</address>
|
||||
<a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a>
|
||||
<br>
|
||||
Last modified: $Date$
|
||||
</div>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@@ -7,9 +7,7 @@
|
||||
</head>
|
||||
<body>
|
||||
|
||||
<div class="doc_title">
|
||||
LLVM 1.1 Release Notes
|
||||
</div>
|
||||
<div class="doc_title">LLVM 1.1 Release Notes</div>
|
||||
|
||||
<ol>
|
||||
<li><a href="#intro">Introduction</a></li>
|
||||
@@ -18,7 +16,6 @@
|
||||
<li><a href="#install-instructions">Installation Instructions</a></li>
|
||||
<li><a href="#knownproblems">Known Problems</a>
|
||||
<ul>
|
||||
<!-- <li><a href="#portabilityprobs">Portability Problems</a> -->
|
||||
<li><a href="#core">Known problems with the LLVM Core</a>
|
||||
<li><a href="#c-fe">Known problems with the C Front-end</a>
|
||||
<li><a href="#c++-fe">Known problems with the C++ Front-end</a>
|
||||
@@ -30,7 +27,7 @@
|
||||
</ol>
|
||||
|
||||
<div class="doc_text">
|
||||
<p><b>Written by <a href="mailto:sabre@nondot.org">Chris Lattner</a></b><p>
|
||||
<p><b>Written by the <a href="http://llvm.cs.uiuc.edu">LLVM team</a></b><p>
|
||||
</div>
|
||||
|
||||
<!-- *********************************************************************** -->
|
||||
@@ -43,10 +40,10 @@
|
||||
|
||||
<p>This document contains the release notes for the LLVM compiler
|
||||
infrastructure, release 1.1. Here we describe the status of LLVM, including any
|
||||
known problems, and bug fixes from the previous release. The most up-to-date
|
||||
known problems and bug fixes from the previous release. The most up-to-date
|
||||
version of this document can be found on the <a
|
||||
href="http://llvm.cs.uiuc.edu/releases/1.1/">LLVM 1.1 web site</a>. If you are
|
||||
not reading this on the LLVM web pages, you should probably go there, because
|
||||
not reading this on the LLVM web pages, you should probably go there because
|
||||
this document may be updated after the release.</p>
|
||||
|
||||
<p>For more information about LLVM, including information about potentially more
|
||||
@@ -72,23 +69,27 @@ href="http://llvm.cs.uiuc.edu/releases/">releases page</a>.</p>
|
||||
|
||||
<p>This is the second public release of the LLVM compiler infrastructure. This
|
||||
release is primarily a bugfix release, dramatically improving the C/C++
|
||||
front-end, and improving support for C++ in the LLVM core. This release also
|
||||
includes a few new features, such as a simple profiler, support for Mac OS/X,
|
||||
front-end and improving support for C++ in the LLVM core. This release also
|
||||
includes a few new features, such as a simple profiler, support for Mac OS X,
|
||||
better interoperability with external source bases, a new example language
|
||||
front-end, and improvements in a few optimizations.</p>
|
||||
front-end, and improvements in a few optimizations. The performance of several
|
||||
LLVM components has been improved, and several gratuitous type-safety issues in
|
||||
the C front-end have been fixed.</p>
|
||||
|
||||
<p>At this time, LLVM is known to correctly compile the C & C++ SPEC CPU2000
|
||||
benchmarks with the C backend (X86 only), the Olden benchmarks, and the Ptrdist
|
||||
benchmarks. It has also been used to compile
|
||||
<b>many</b> other programs. LLVM now also works with a broad variety of
|
||||
C++ programs, though it has still received much less testing than the C
|
||||
front-end.
|
||||
<p>At this time, LLVM is known to correctly compile and run all non-unwinding C
|
||||
& C++ SPEC CPU2000 benchmarks, the Olden benchmarks, and the Ptrdist
|
||||
benchmarks. It has also been used to compile <b>many</b> other programs. LLVM
|
||||
now also works with a broad variety of C++ programs, though it has still
|
||||
received much less testing than the C front-end.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Note that the Sparc and X86 backends do not currently support exception throwing
|
||||
or long jumping (including 253.perlbmk in SPEC). For these programs, you must
|
||||
use the C backend. Support for unwinding will be added in a future release.
|
||||
The LLVM native code generators are very stable but do not currently support
|
||||
unwinding (exception throwing or <tt>longjmp</tt>ing), which prevent them from
|
||||
working with programs like the <tt>253.perlbmk</tt> in SPEC CPU2000. The C
|
||||
backend and the rest of LLVM supports these programs, so you can
|
||||
still use LLVM with them. Support for unwinding will be added in a future
|
||||
release.
|
||||
</p>
|
||||
|
||||
|
||||
@@ -100,15 +101,15 @@ This release implements the following new features:
|
||||
<ol>
|
||||
<li><a
|
||||
href="http://mail.cs.uiuc.edu/pipermail/llvmdev/2003-November/000528.html">A new
|
||||
LLVM profiler, similar to gprof</a> is available</li>
|
||||
LLVM profiler, similar to gprof,</a> is available.</li>
|
||||
|
||||
<li>LLVM and the C/C++ front-end now compile on Mac OS/X! Mac OS/X users can
|
||||
<li>LLVM and the C/C++ front-end now compile on Mac OS X! Mac OS X users can
|
||||
now explore the LLVM optimizer with the C backend and interpreter. Note that
|
||||
LLVM requires GCC 3.3 on Mac OS/X.</li>
|
||||
LLVM requires GCC 3.3 on Mac OS X.</li>
|
||||
|
||||
<li>LLVM has been <a
|
||||
href="http://mail.cs.uiuc.edu/pipermail/llvmdev/2003-November/000554.html">moved
|
||||
into an 'llvm' C++ namespace</a>, for easier integration with third-party
|
||||
into an 'llvm' C++ namespace</a> for easier integration with third-party
|
||||
code. Note that due to lack of namespace support in GDB 5.x, you will probably
|
||||
want to upgrade to GDB 6 or better to debug LLVM code.</li>
|
||||
|
||||
@@ -118,7 +119,8 @@ object tree as subdirectories are built. This means that:
|
||||
<ol>
|
||||
<li>
|
||||
New directories can be added to the source tree, and the build will
|
||||
automatically pick them up (i.e. no need to re-run <tt>configure</tt>).
|
||||
automatically pick them up (i.e. no need to edit <tt>configure.ac</tt> and
|
||||
re-run <tt>configure</tt>).
|
||||
</li>
|
||||
|
||||
<li>
|
||||
@@ -130,7 +132,9 @@ object tree as subdirectories are built. This means that:
|
||||
|
||||
<li>A front-end for "Stacker" (a simple Forth-like language) is now
|
||||
<a href="http://llvm.cs.uiuc.edu/PR136">included in the main LLVM tree</a>.
|
||||
Additionally, Reid Spencer, the author, contributed a document <a href="Stacker.html">describing his experiences writing Stacker, and the language itself</a>. This document is invaluable for others writing front-ends targetting LLVM.</li>
|
||||
Additionally, Reid Spencer, the author, contributed a document
|
||||
<a href="Stacker.html">describing his experiences writing Stacker and the language itself</a>.
|
||||
This document is invaluable for others writing front-ends targetting LLVM.</li>
|
||||
|
||||
<li>The <tt>configure</tt> script will now configure all projects placed in the
|
||||
<tt>llvm/projects</tt> directory.</li>
|
||||
@@ -141,12 +145,12 @@ object tree as subdirectories are built. This means that:
|
||||
<li>The <tt>-licm</tt> pass can now sink instructions out the bottom of loops
|
||||
in addition to being able to hoist them out the top.</li>
|
||||
|
||||
<li>The <tt>-basicaa</tt> pass (the default alias analysis) has been upgraded
|
||||
to be <a href="http://llvm.cs.uiuc.edu/PR86">significantly more
|
||||
<li>The <tt>-basicaa</tt> pass (the default alias analysis pass) has been
|
||||
upgraded to be <a href="http://llvm.cs.uiuc.edu/PR86">significantly more
|
||||
precise</a>.</li>
|
||||
|
||||
<li>LLVM 1.1 implements a simple size optimization for LLVM bytecode files.
|
||||
This means that the 1.1 files are smaller than 1.0, but that 1.0 won't
|
||||
This means that the 1.1 files are smaller than 1.0, but LLVM 1.0 won't
|
||||
read 1.1 bytecode files.</li>
|
||||
|
||||
<li><a href="http://llvm.cs.uiuc.edu/PR140">The gccld program produces a runner script that includes command-line options to load the necessary shared objects.</a></li>
|
||||
@@ -183,15 +187,15 @@ fixed:
|
||||
|
||||
<li>The C++ front-end now compiles functions to
|
||||
<a href="http://llvm.cs.uiuc.edu/PR29">use the linkonce linkage type</a>
|
||||
more, giving the optimizer more freedom.</a></li>
|
||||
more, giving the optimizer more freedom.</li>
|
||||
|
||||
<li>The C front-end now <a href="http://llvm.cs.uiuc.edu/PR84">generates
|
||||
type-safe code</a> in several cases that it did not before, which prevented
|
||||
some important optimizations.</li>
|
||||
type-safe code</a> in several cases that it did not before, allowing
|
||||
optimization of code that could not be optimized previously.</li>
|
||||
|
||||
<li>The LLVM build system has been taught to catch some common configuration
|
||||
problems that <a href="http://llvm.cs.uiuc.edu/PR96">caused it to get
|
||||
horribly confused</a> before.</li>
|
||||
horribly confused</a>.</li>
|
||||
|
||||
<li>The LLVM header files are now
|
||||
<a href="http://llvm.cs.uiuc.edu/PR114">-Wold-style-cast clean</a>.</li>
|
||||
@@ -208,8 +212,9 @@ cases).</li>
|
||||
<a href="http://llvm.cs.uiuc.edu/PR11">generated N^2 amounts of duplicated cleanup code</a> in some cases.</li>
|
||||
|
||||
<li>The JIT used to <a href="http://llvm.cs.uiuc.edu/PR177">generate code for
|
||||
all functions pointed to by globals</a> immediately, before the program
|
||||
started execution, but now it waits until the first time they are called to
|
||||
all functions pointed to by globals</a> before the program
|
||||
started execution. Now, it waits until the first time the functions are
|
||||
called to
|
||||
compile them. This dramatically speeds up short runs of large C++ programs,
|
||||
which often have large numbers of functions pointed to by vtables.</li>
|
||||
</ol>
|
||||
@@ -231,7 +236,7 @@ In this release, the following bugs in the previous release were fixed:
|
||||
<li><a href="http://llvm.cs.uiuc.edu/PR71">llvm-as crashes when labels are used in phi nodes</a></li>
|
||||
<li><a href="http://llvm.cs.uiuc.edu/PR72">[build problem] Callgraph.cpp not pulled in from libipa.a</a></li>
|
||||
<li><a href="http://llvm.cs.uiuc.edu/PR77">Variables in scope of output setjmp
|
||||
calls should be volatile</a> (Note that this does not effect correctness on
|
||||
calls should be volatile</a> (Note that this does not affect correctness on
|
||||
many platforms, such as X86).</li>
|
||||
<li><a href="http://llvm.cs.uiuc.edu/PR83">[X86] Emission of global bool initializers broken</a></li>
|
||||
<li><a href="http://llvm.cs.uiuc.edu/PR91">[gccld] The -r (relinking) option does not work correctly</a></li>
|
||||
@@ -248,6 +253,7 @@ many platforms, such as X86).</li>
|
||||
<li><a href="http://llvm.cs.uiuc.edu/PR123">[X86] div and rem constant exprs invalidate iterators!</a></li>
|
||||
<li><a href="http://llvm.cs.uiuc.edu/PR130">[vmcore] Symbol table doesn't rename colliding variables during type resolution</a></li>
|
||||
<li><a href="http://llvm.cs.uiuc.edu/PR138">Archive reader does not understand 4.4BSD/Mac OS X long filenames</a></li>
|
||||
<li><a href="http://llvm.cs.uiuc.edu/PR30">[llvm-ar] Command line arguments have funny syntax</a></li>
|
||||
</ol>
|
||||
|
||||
|
||||
@@ -266,7 +272,7 @@ many platforms, such as X86).</li>
|
||||
<li><a href="http://llvm.cs.uiuc.edu/PR81">CFrontend crashes when compiling C99 compound expressions</a></li>
|
||||
<li><a href="http://llvm.cs.uiuc.edu/PR87">llvm-gcc infinite loops on "case MAXINT:"</a></li>
|
||||
<li><a href="http://llvm.cs.uiuc.edu/PR89">[C++] Catch blocks make unparsable labels</a></li>
|
||||
<li><a href="http://llvm.cs.uiuc.edu/PR90">[C++] Initializing array with constructable objects fail</a></li>
|
||||
<li><a href="http://llvm.cs.uiuc.edu/PR90">[C++] Initializing array with constructible objects fail</a></li>
|
||||
<li><a href="http://llvm.cs.uiuc.edu/PR94">llvm-gcc tries to add bools</a></li>
|
||||
<li><a href="http://llvm.cs.uiuc.edu/PR104">[c++] C++ Frontend lays out superclasses like anonymous bitfields!</a></li>
|
||||
<li><a href="http://llvm.cs.uiuc.edu/PR54">C front-end miscompiles unsigned enums whose LLVM types are signed</a></li>
|
||||
@@ -301,11 +307,11 @@ many platforms, such as X86).</li>
|
||||
<p>LLVM has been extensively tested on Intel and AMD machines running Red
|
||||
Hat Linux and has been tested on Sun UltraSPARC workstations running Solaris 8.
|
||||
Additionally,
|
||||
LLVM works on Mac OS/X 10.3 and above, but only with the C backend or
|
||||
LLVM works on Mac OS X 10.3 and above, but only with the C backend or
|
||||
interpreter (no native backend for the PowerPC is available yet).
|
||||
The core LLVM infrastructure uses "autoconf" for portability, so hopefully we
|
||||
work on more platforms than that. However, it is likely that we
|
||||
missed something, and that minor porting is required to get LLVM to work on
|
||||
missed something and that minor porting is required to get LLVM to work on
|
||||
new platforms. We welcome portability patches and error messages.</p>
|
||||
|
||||
</div>
|
||||
@@ -320,7 +326,9 @@ new platforms. We welcome portability patches and error messages.</p>
|
||||
|
||||
<p>This section contains all known problems with the LLVM system, listed by
|
||||
component. As new problems are discovered, they will be added to these
|
||||
sections.</p>
|
||||
sections. If you run into a problem, please check the <a
|
||||
href="http://llvm.cs.uiuc.edu/bugs/">LLVM bug database</a> and submit a bug if
|
||||
there isn't already one.</p>
|
||||
|
||||
</div>
|
||||
|
||||
@@ -354,6 +362,18 @@ table in the archive).</li>
|
||||
<li><a href="http://llvm.cs.uiuc.edu/PR82">LLVM cannot handle structures with
|
||||
more than 256 elements</a>.</li>
|
||||
|
||||
<li>
|
||||
The gccld program
|
||||
<a href="http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=139">
|
||||
does not link objects/archives in the order specified on the command line.
|
||||
</a>
|
||||
</li>
|
||||
|
||||
<li>
|
||||
<a href="http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=174">
|
||||
Tail duplication does not update SSA form correctly.
|
||||
</a>
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
</div>
|
||||
@@ -369,9 +389,7 @@ more than 256 elements</a>.</li>
|
||||
</div>
|
||||
|
||||
<div class="doc_text">
|
||||
|
||||
<ul>
|
||||
|
||||
<li>C99 Variable sized arrays do not release stack memory when they go out of
|
||||
scope. Thus, the following program may run out of stack space:
|
||||
<pre>
|
||||
@@ -381,8 +399,27 @@ more than 256 elements</a>.</li>
|
||||
}
|
||||
</pre></li>
|
||||
|
||||
</ul>
|
||||
<li>
|
||||
Initialization of global union variables can only be done
|
||||
<a href="http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=162">with the largest
|
||||
union member</a>.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
<a href="http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=182">
|
||||
Functions marked "extern inline" are not compiled into LLVM with linkonce
|
||||
linkage.
|
||||
</a>
|
||||
</li>
|
||||
|
||||
|
||||
<li>
|
||||
The memory management functions in the libc runtime
|
||||
<a href="http://llvm.cs.uiuc.edu/PR186">need weak linkage so that they can be
|
||||
overridden.
|
||||
</a>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<!-- _______________________________________________________________________ -->
|
||||
@@ -414,11 +451,11 @@ work:
|
||||
the following extensions are known to <b>not be</b> supported:
|
||||
<ol>
|
||||
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Local-Labels.html#Local%20Labels">Local Labels</a>: Labels local to a block.</li>
|
||||
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html#Labels%20as%20Values">Labels as Values</a>: Getting pointers to labels, and computed gotos.</li>
|
||||
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html#Labels%20as%20Values">Labels as Values</a>: Getting pointers to labels and computed gotos.</li>
|
||||
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html#Nested%20Functions">Nested Functions</a>: As in Algol and Pascal, lexical scoping of functions.</li>
|
||||
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Constructing-Calls.html#Constructing%20Calls">Constructing Calls</a>: Dispatching a call to another function.</li>
|
||||
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Extended%20Asm">Extended Asm</a>: Assembler instructions with C expressions as operands.</li>
|
||||
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Constraints.html#Constraints">Constraints</a>: Constraints for asm operands</li>
|
||||
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Constraints.html#Constraints">Constraints</a>: Constraints for asm operands.</li>
|
||||
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Asm-Labels.html#Asm%20Labels">Asm Labels</a>: Specifying the assembler name to use for a C symbol.</li>
|
||||
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Explicit-Reg-Vars.html#Explicit%20Reg%20Vars">Explicit Reg Vars</a>: Defining variables residing in specified registers.</li>
|
||||
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Return-Address.html#Return%20Address">Return Address</a>: Getting the return or frame address of a function.</li>
|
||||
@@ -431,7 +468,7 @@ work:
|
||||
<p>The following GCC extensions are <b>partially</b> supported. An ignored
|
||||
attribute means that the LLVM compiler ignores the presence of the attribute,
|
||||
but the code should still work. An unsupported attribute is one which is
|
||||
ignored by the LLVM compiler, which will cause a different interpretation of
|
||||
ignored by the LLVM compiler and will cause a different interpretation of
|
||||
the program.</p>
|
||||
|
||||
<ol>
|
||||
@@ -441,7 +478,7 @@ work:
|
||||
|
||||
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#Function%20Attributes">Function Attributes</a>:
|
||||
|
||||
Declaring that functions have no side effects, or that they can never
|
||||
Declaring that functions have no side effects or that they can never
|
||||
return.<br>
|
||||
|
||||
<b>Supported:</b> <tt>format</tt>, <tt>format_arg</tt>, <tt>non_null</tt>,
|
||||
@@ -500,7 +537,8 @@ work:
|
||||
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Subscripting.html#Subscripting">Subscripting</a>: Any array can be subscripted, even if not an lvalue.</li>
|
||||
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html#Pointer%20Arith">Pointer Arith</a>: Arithmetic on <code>void</code>-pointers and function pointers.</li>
|
||||
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Initializers.html#Initializers">Initializers</a>: Non-constant initializers.</li>
|
||||
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Compound-Literals.html#Compound%20Literals">Compound Literals</a>: Compound literals give structures, unions or arrays as values.</li>
|
||||
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Compound-Literals.html#Compound%20Literals">Compound Literals</a>: Compound literals give structures, unions,
|
||||
or arrays as values.</li>
|
||||
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html#Designated%20Inits">Designated Inits</a>: Labeling elements of initializers.</li>
|
||||
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Cast-to-Union.html#Cast%20to%20Union">Cast to Union</a>: Casting to union type from any member of the union.</li>
|
||||
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Case-Ranges.html#Case%20Ranges">Case Ranges</a>: `case 1 ... 9' and such.</li>
|
||||
@@ -532,7 +570,7 @@ lists, please let us know (also including whether or not they work).</p>
|
||||
|
||||
<div class="doc_text">
|
||||
|
||||
<p>For this release, the C++ front-end is considered to be fully functional, but
|
||||
<p>For this release, the C++ front-end is considered to be fully functional but
|
||||
has not been tested as thoroughly as the C front-end. It has been tested and
|
||||
works for a number of non-trivial programs, but there may be lurking bugs.
|
||||
Please report any bugs or problems.</p>
|
||||
@@ -548,9 +586,14 @@ Please report any bugs or problems.</p>
|
||||
|
||||
<ul>
|
||||
<li>The C++ front-end inherits all problems afflicting the <a href="#c-fe">C
|
||||
front-end</a></li>
|
||||
</ul>
|
||||
front-end</a>.</li>
|
||||
|
||||
<li>
|
||||
<a href="http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=137">
|
||||
Code is generated for empty classes.
|
||||
</a>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<!-- _______________________________________________________________________ -->
|
||||
@@ -570,7 +613,7 @@ href="http://gcc.gnu.org/gcc-3.4/changes.html">GCC 3.4 release notes</a>.</li>
|
||||
<li>Destructors for local objects are not always run when a <tt>longjmp</tt> is
|
||||
performed. In particular, destructors for objects in the <tt>longjmp</tt>ing
|
||||
function and in the <tt>setjmp</tt> receiver function may not be run.
|
||||
Objects in intervening stack frames will be destroyed however (which is
|
||||
Objects in intervening stack frames will be destroyed, however (which is
|
||||
better than most compilers).</li>
|
||||
|
||||
<li>The LLVM C++ front-end follows the <a
|
||||
@@ -620,6 +663,11 @@ href="http://llvm.cs.uiuc.edu/PR15">does not currently
|
||||
support the <tt>unwind</tt> instruction</a>, so code that throws a C++ exception
|
||||
or calls the C <tt>longjmp</tt> function will abort.</li>
|
||||
|
||||
<li>
|
||||
<a href="http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=167">
|
||||
The llc program can crash on legal code.
|
||||
</a>
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
</div>
|
||||
@@ -659,14 +707,15 @@ frontends.</li>
|
||||
<div class="doc_text">
|
||||
|
||||
<p>A wide variety of additional information is available on the LLVM web page,
|
||||
including mailing lists publications describing algorithms and components
|
||||
including mailing lists and publications describing algorithms and components
|
||||
implemented in LLVM. The web page also contains versions of the API
|
||||
documentation which is up-to-date with the CVS version of the source code. You
|
||||
can access versions of these documents specific to this release by going into
|
||||
the "<tt>llvm/doc/</tt>" directory in the LLVM tree.</p>
|
||||
|
||||
<p>If you have any questions or comments about LLVM, please feel free to contact
|
||||
us via the mailing lists.</p>
|
||||
us via the <a href="http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev">mailing
|
||||
lists</a>.</p>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
@@ -61,7 +61,7 @@
|
||||
about LLVM through the experience of creating a simple programming language
|
||||
named Stacker. Stacker was invented specifically as a demonstration of
|
||||
LLVM. The emphasis in this document is not on describing the
|
||||
intricacies of LLVM itself, but on how to use it to build your own
|
||||
intricacies of LLVM itself but on how to use it to build your own
|
||||
compiler system.</p>
|
||||
</div>
|
||||
<!-- ======================================================================= -->
|
||||
@@ -70,7 +70,7 @@ compiler system.</p>
|
||||
<p>Amongst other things, LLVM is a platform for compiler writers.
|
||||
Because of its exceptionally clean and small IR (intermediate
|
||||
representation), compiler writing with LLVM is much easier than with
|
||||
other system. As proof, the author of Stacker wrote the entire
|
||||
other systems. As proof, the author of Stacker wrote the entire
|
||||
compiler (language definition, lexer, parser, code generator, etc.) in
|
||||
about <em>four days</em>! That's important to know because it shows
|
||||
how quickly you can get a new
|
||||
@@ -78,11 +78,11 @@ language up when using LLVM. Furthermore, this was the <em >first</em>
|
||||
language the author ever created using LLVM. The learning curve is
|
||||
included in that four days.</p>
|
||||
<p>The language described here, Stacker, is Forth-like. Programs
|
||||
are simple collections of word definitions and the only thing definitions
|
||||
are simple collections of word definitions, and the only thing definitions
|
||||
can do is manipulate a stack or generate I/O. Stacker is not a "real"
|
||||
programming language; its very simple. Although it is computationally
|
||||
programming language; it's very simple. Although it is computationally
|
||||
complete, you wouldn't use it for your next big project. However,
|
||||
the fact that it is complete, its simple, and it <em>doesn't</em> have
|
||||
the fact that it is complete, it's simple, and it <em>doesn't</em> have
|
||||
a C-like syntax make it useful for demonstration purposes. It shows
|
||||
that LLVM could be applied to a wide variety of languages.</p>
|
||||
<p>The basic notions behind stacker is very simple. There's a stack of
|
||||
@@ -96,11 +96,11 @@ program in Stacker:</p>
|
||||
: MAIN hello_world ;<br></code></p>
|
||||
<p>This has two "definitions" (Stacker manipulates words, not
|
||||
functions and words have definitions): <code>MAIN</code> and <code>
|
||||
hello_world</code>. The <code>MAIN</code> definition is standard, it
|
||||
hello_world</code>. The <code>MAIN</code> definition is standard; it
|
||||
tells Stacker where to start. Here, <code>MAIN</code> is defined to
|
||||
simply invoke the word <code>hello_world</code>. The
|
||||
<code>hello_world</code> definition tells stacker to push the
|
||||
<code>"Hello, World!"</code> string onto the stack, print it out
|
||||
<code>"Hello, World!"</code> string on to the stack, print it out
|
||||
(<code>>s</code>), pop it off the stack (<code>DROP</code>), and
|
||||
finally print a carriage return (<code>CR</code>). Although
|
||||
<code>hello_world</code> uses the stack, its net effect is null. Well
|
||||
@@ -124,7 +124,7 @@ learned. Those lessons are described in the following subsections.<p>
|
||||
<p>Although I knew that LLVM uses a Single Static Assignment (SSA) format,
|
||||
it wasn't obvious to me how prevalent this idea was in LLVM until I really
|
||||
started using it. Reading the <a href="ProgrammersManual.html">
|
||||
Programmer's Manual</a> and <a href="LangRef.html">Language Reference</a>
|
||||
Programmer's Manual</a> and <a href="LangRef.html">Language Reference</a>,
|
||||
I noted that most of the important LLVM IR (Intermediate Representation) C++
|
||||
classes were derived from the Value class. The full power of that simple
|
||||
design only became fully understood once I started constructing executable
|
||||
@@ -200,7 +200,7 @@ should be constructed. In general, here's what I learned:
|
||||
<ol>
|
||||
<li><em>Create your blocks early.</em> While writing your compiler, you
|
||||
will encounter several situations where you know apriori that you will
|
||||
need several blocks. For example, if-then-else, switch, while and for
|
||||
need several blocks. For example, if-then-else, switch, while, and for
|
||||
statements in C/C++ all need multiple blocks for expression in LVVM.
|
||||
The rule is, create them early.</li>
|
||||
<li><em>Terminate your blocks early.</em> This just reduces the chances
|
||||
@@ -261,15 +261,15 @@ MyCompiler::handle_if( BasicBlock* bb, SetCondInst* condition )
|
||||
the instructions for the "then" and "else" parts. They would use the third part
|
||||
of the idiom almost exclusively (inserting new instructions before the
|
||||
terminator). Furthermore, they could even recurse back to <code>handle_if</code>
|
||||
should they encounter another if/then/else statement and it will just work.</p>
|
||||
should they encounter another if/then/else statement, and it will just work.</p>
|
||||
<p>Note how cleanly this all works out. In particular, the push_back methods on
|
||||
the <code>BasicBlock</code>'s instruction list. These are lists of type
|
||||
<code>Instruction</code> which also happen to be <code>Value</code>s. To create
|
||||
the "if" branch we merely instantiate a <code>BranchInst</code> that takes as
|
||||
the "if" branch, we merely instantiate a <code>BranchInst</code> that takes as
|
||||
arguments the blocks to branch to and the condition to branch on. The blocks
|
||||
act like branch labels! This new <code>BranchInst</code> terminates
|
||||
the <code>BasicBlock</code> provided as an argument. To give the caller a way
|
||||
to keep inserting after calling <code>handle_if</code> we create an "exit" block
|
||||
to keep inserting after calling <code>handle_if</code>, we create an "exit" block
|
||||
which is returned to the caller. Note that the "exit" block is used as the
|
||||
terminator for both the "then" and the "else" blocks. This guarantees that no
|
||||
matter what else "handle_if" or "fill_in" does, they end up at the "exit" block.
|
||||
@@ -283,7 +283,7 @@ One of the first things I noticed is the frequent use of the "push_back"
|
||||
method on the various lists. This is so common that it is worth mentioning.
|
||||
The "push_back" inserts a value into an STL list, vector, array, etc. at the
|
||||
end. The method might have also been named "insert_tail" or "append".
|
||||
Althought I've used STL quite frequently, my use of push_back wasn't very
|
||||
Although I've used STL quite frequently, my use of push_back wasn't very
|
||||
high in other programs. In LLVM, you'll use it all the time.
|
||||
</p>
|
||||
</div>
|
||||
@@ -292,17 +292,17 @@ high in other programs. In LLVM, you'll use it all the time.
|
||||
<div class="doc_text">
|
||||
<p>
|
||||
It took a little getting used to and several rounds of postings to the LLVM
|
||||
mail list to wrap my head around this instruction correctly. Even though I had
|
||||
mailing list to wrap my head around this instruction correctly. Even though I had
|
||||
read the Language Reference and Programmer's Manual a couple times each, I still
|
||||
missed a few <em>very</em> key points:
|
||||
</p>
|
||||
<ul>
|
||||
<li>GetElementPtrInst gives you back a Value for the last thing indexed</em>
|
||||
<li>GetElementPtrInst gives you back a Value for the last thing indexed.</em>
|
||||
<li>All global variables in LLVM are <em>pointers</em>.
|
||||
<li>Pointers must also be dereferenced with the GetElementPtrInst instruction.
|
||||
</ul>
|
||||
<p>This means that when you look up an element in the global variable (assuming
|
||||
its a struct or array), you <em>must</em> deference the pointer first! For many
|
||||
it's a struct or array), you <em>must</em> deference the pointer first! For many
|
||||
things, this leads to the idiom:
|
||||
</p>
|
||||
<pre><code>
|
||||
@@ -319,13 +319,13 @@ will run against your grain because you'll naturally think of the global array
|
||||
variable and the address of its first element as the same. That tripped me up
|
||||
for a while until I realized that they really do differ .. by <em>type</em>.
|
||||
Remember that LLVM is a strongly typed language itself. Everything
|
||||
has a type. The "type" of the global variable is [24 x int]*. That is, its
|
||||
has a type. The "type" of the global variable is [24 x int]*. That is, it's
|
||||
a pointer to an array of 24 ints. When you dereference that global variable with
|
||||
a single (0) index, you now have a "[24 x int]" type. Although
|
||||
the pointer value of the dereferenced global and the address of the zero'th element
|
||||
in the array will be the same, they differ in their type. The zero'th element has
|
||||
type "int" while the pointer value has type "[24 x int]".</p>
|
||||
<p>Get this one aspect of LLVM right in your head and you'll save yourself
|
||||
<p>Get this one aspect of LLVM right in your head, and you'll save yourself
|
||||
a lot of compiler writing headaches down the road.</p>
|
||||
</div>
|
||||
<!-- ======================================================================= -->
|
||||
@@ -334,7 +334,7 @@ a lot of compiler writing headaches down the road.</p>
|
||||
<p>Linkage types in LLVM can be a little confusing, especially if your compiler
|
||||
writing mind has affixed very hard concepts to particular words like "weak",
|
||||
"external", "global", "linkonce", etc. LLVM does <em>not</em> use the precise
|
||||
definitions of say ELF or GCC even though they share common terms. To be fair,
|
||||
definitions of, say, ELF or GCC, even though they share common terms. To be fair,
|
||||
the concepts are related and similar but not precisely the same. This can lead
|
||||
you to think you know what a linkage type represents but in fact it is slightly
|
||||
different. I recommend you read the
|
||||
@@ -342,10 +342,10 @@ different. I recommend you read the
|
||||
carefully. Then, read it again.<p>
|
||||
<p>Here are some handy tips that I discovered along the way:</p>
|
||||
<ul>
|
||||
<li>Unitialized means external. That is, the symbol is declared in the current
|
||||
<li>Uninitialized means external. That is, the symbol is declared in the current
|
||||
module and can be used by that module but it is not defined by that module.</li>
|
||||
<li>Setting an initializer changes a global's linkage type from whatever it was
|
||||
to a normal, defind global (not external). You'll need to call the setLinkage()
|
||||
to a normal, defined global (not external). You'll need to call the setLinkage()
|
||||
method to reset it if you specify the initializer after the GlobalValue has been
|
||||
constructed. This is important for LinkOnce and Weak linkage types.</li>
|
||||
<li>Appending linkage can be used to keep track of compilation information at
|
||||
@@ -362,7 +362,7 @@ Constants in LLVM took a little getting used to until I discovered a few utility
|
||||
functions in the LLVM IR that make things easier. Here's what I learned: </p>
|
||||
<ul>
|
||||
<li>Constants are Values like anything else and can be operands of instructions</li>
|
||||
<li>Integer constants, frequently needed can be created using the static "get"
|
||||
<li>Integer constants, frequently needed, can be created using the static "get"
|
||||
methods of the ConstantInt, ConstantSInt, and ConstantUInt classes. The nice thing
|
||||
about these is that you can "get" any kind of integer quickly.</li>
|
||||
<li>There's a special method on Constant class which allows you to get the null
|
||||
@@ -379,14 +379,14 @@ functions in the LLVM IR that make things easier. Here's what I learned: </p>
|
||||
proceeding, a few words about the stack are in order. The stack is simply
|
||||
a global array of 32-bit integers or pointers. A global index keeps track
|
||||
of the location of the top of the stack. All of this is hidden from the
|
||||
programmer but it needs to be noted because it is the foundation of the
|
||||
programmer, but it needs to be noted because it is the foundation of the
|
||||
conceptual programming model for Stacker. When you write a definition,
|
||||
you are, essentially, saying how you want that definition to manipulate
|
||||
the global stack.</p>
|
||||
<p>Manipulating the stack can be quite hazardous. There is no distinction
|
||||
given and no checking for the various types of values that can be placed
|
||||
on the stack. Automatic coercion between types is performed. In many
|
||||
cases this is useful. For example, a boolean value placed on the stack
|
||||
cases, this is useful. For example, a boolean value placed on the stack
|
||||
can be interpreted as an integer with good results. However, using a
|
||||
word that interprets that boolean value as a pointer to a string to
|
||||
print out will almost always yield a crash. Stacker simply leaves it
|
||||
@@ -406,9 +406,9 @@ is terminated by a semi-colon.</p>
|
||||
<p>So, your typical definition will have the form:</p>
|
||||
<pre><code>: name ... ;</code></pre>
|
||||
<p>The <code>name</code> is up to you but it must start with a letter and contain
|
||||
only letters numbers and underscore. Names are case sensitive and must not be
|
||||
only letters, numbers, and underscore. Names are case sensitive and must not be
|
||||
the same as the name of a built-in word. The <code>...</code> is replaced by
|
||||
the stack manipulting words that you wish define <code>name</code> as. <p>
|
||||
the stack manipulating words that you wish to define <code>name</code> as. <p>
|
||||
</div>
|
||||
<!-- ======================================================================= -->
|
||||
<div class="doc_subsection"><a name="comments"></a>Comments</div>
|
||||
@@ -429,12 +429,12 @@ a real program.</p>
|
||||
<!-- ======================================================================= -->
|
||||
<div class="doc_subsection"><a name="literals"></a>Literals</div>
|
||||
<div class="doc_text">
|
||||
<p>There are three kinds of literal values in Stacker. Integer, Strings,
|
||||
<p>There are three kinds of literal values in Stacker: Integers, Strings,
|
||||
and Booleans. In each case, the stack operation is to simply push the
|
||||
value onto the stack. So, for example:<br/>
|
||||
value on to the stack. So, for example:<br/>
|
||||
<code> 42 " is the answer." TRUE </code><br/>
|
||||
will push three values onto the stack: the integer 42, the
|
||||
string " is the answer." and the boolean TRUE.</p>
|
||||
will push three values on to the stack: the integer 42, the
|
||||
string " is the answer.", and the boolean TRUE.</p>
|
||||
</div>
|
||||
<!-- ======================================================================= -->
|
||||
<div class="doc_subsection"><a name="words"></a>Words</div>
|
||||
@@ -464,20 +464,20 @@ linking.</p>
|
||||
<p>The built-in words of the Stacker language are put in several groups
|
||||
depending on what they do. The groups are as follows:</p>
|
||||
<ol>
|
||||
<li><em>Logical</em>These words provide the logical operations for
|
||||
<li><em>Logical</em>: These words provide the logical operations for
|
||||
comparing stack operands.<br/>The words are: < > <= >=
|
||||
= <> true false.</li>
|
||||
<li><em>Bitwise</em>These words perform bitwise computations on
|
||||
<li><em>Bitwise</em>: These words perform bitwise computations on
|
||||
their operands. <br/> The words are: << >> XOR AND NOT</li>
|
||||
<li><em>Arithmetic</em>These words perform arithmetic computations on
|
||||
<li><em>Arithmetic</em>: These words perform arithmetic computations on
|
||||
their operands. <br/> The words are: ABS NEG + - * / MOD */ ++ -- MIN MAX</li>
|
||||
<li><em>Stack</em>These words manipulate the stack directly by moving
|
||||
<li><em>Stack</em>: These words manipulate the stack directly by moving
|
||||
its elements around.<br/> The words are: DROP DUP SWAP OVER ROT DUP2 DROP2 PICK TUCK</li>
|
||||
<li><em>Memory</em>These words allocate, free and manipulate memory
|
||||
<li><em>Memory</em>: These words allocate, free, and manipulate memory
|
||||
areas outside the stack.<br/>The words are: MALLOC FREE GET PUT</li>
|
||||
<li><em>Control</em>These words alter the normal left to right flow
|
||||
<li><em>Control</em>: These words alter the normal left to right flow
|
||||
of execution.<br/>The words are: IF ELSE ENDIF WHILE END RETURN EXIT RECURSE</li>
|
||||
<li><em>I/O</em> These words perform output on the standard output
|
||||
<li><em>I/O</em>: These words perform output on the standard output
|
||||
and input on the standard input. No other I/O is possible in Stacker.
|
||||
<br/>The words are: SPACE TAB CR >s >d >c <s <d <c.</li>
|
||||
</ol>
|
||||
@@ -554,12 +554,12 @@ using the following construction:</p>
|
||||
<tr><td>FALSE</td>
|
||||
<td>FALSE</td>
|
||||
<td> -- b</td>
|
||||
<td>The boolean value FALSE (0) is pushed onto the stack.</td>
|
||||
<td>The boolean value FALSE (0) is pushed on to the stack.</td>
|
||||
</tr>
|
||||
<tr><td>TRUE</td>
|
||||
<td>TRUE</td>
|
||||
<td> -- b</td>
|
||||
<td>The boolean value TRUE (-1) is pushed onto the stack.</td>
|
||||
<td>The boolean value TRUE (-1) is pushed on to the stack.</td>
|
||||
</tr>
|
||||
<tr><td colspan="4">BITWISE OPERATIONS</td></tr>
|
||||
<tr><td>Word</td><td>Name</td><td>Operation</td><td>Description</td></tr>
|
||||
@@ -604,75 +604,75 @@ using the following construction:</p>
|
||||
<td>ABS</td>
|
||||
<td>w -- |w|</td>
|
||||
<td>One value s popped off the stack; its absolute value is computed
|
||||
and then pushed onto the stack. If w1 is -1 then w2 is 1. If w1 is
|
||||
and then pushed on to the stack. If w1 is -1 then w2 is 1. If w1 is
|
||||
1 then w2 is also 1.</td>
|
||||
</tr>
|
||||
<tr><td>NEG</td>
|
||||
<td>NEG</td>
|
||||
<td>w -- -w</td>
|
||||
<td>One value is popped off the stack which is negated and then
|
||||
pushed back onto the stack. If w1 is -1 then w2 is 1. If w1 is
|
||||
pushed back on to the stack. If w1 is -1 then w2 is 1. If w1 is
|
||||
1 then w2 is -1.</td>
|
||||
</tr>
|
||||
<tr><td> + </td>
|
||||
<td>ADD</td>
|
||||
<td>w1 w2 -- w2+w1</td>
|
||||
<td>Two values are popped off the stack. Their sum is pushed back
|
||||
onto the stack</td>
|
||||
on to the stack</td>
|
||||
</tr>
|
||||
<tr><td> - </td>
|
||||
<td>SUB</td>
|
||||
<td>w1 w2 -- w2-w1</td>
|
||||
<td>Two values are popped off the stack. Their difference is pushed back
|
||||
onto the stack</td>
|
||||
on to the stack</td>
|
||||
</tr>
|
||||
<tr><td> * </td>
|
||||
<td>MUL</td>
|
||||
<td>w1 w2 -- w2*w1</td>
|
||||
<td>Two values are popped off the stack. Their product is pushed back
|
||||
onto the stack</td>
|
||||
on to the stack</td>
|
||||
</tr>
|
||||
<tr><td> / </td>
|
||||
<td>DIV</td>
|
||||
<td>w1 w2 -- w2/w1</td>
|
||||
<td>Two values are popped off the stack. Their quotient is pushed back
|
||||
onto the stack</td>
|
||||
on to the stack</td>
|
||||
</tr>
|
||||
<tr><td>MOD</td>
|
||||
<td>MOD</td>
|
||||
<td>w1 w2 -- w2%w1</td>
|
||||
<td>Two values are popped off the stack. Their remainder after division
|
||||
of w1 by w2 is pushed back onto the stack</td>
|
||||
of w1 by w2 is pushed back on to the stack</td>
|
||||
</tr>
|
||||
<tr><td> */ </td>
|
||||
<td>STAR_SLAH</td>
|
||||
<td>w1 w2 w3 -- (w3*w2)/w1</td>
|
||||
<td>Three values are popped off the stack. The product of w1 and w2 is
|
||||
divided by w3. The result is pushed back onto the stack.</td>
|
||||
divided by w3. The result is pushed back on to the stack.</td>
|
||||
</tr>
|
||||
<tr><td> ++ </td>
|
||||
<td>INCR</td>
|
||||
<td>w -- w+1</td>
|
||||
<td>One value is popped off the stack. It is incremented by one and then
|
||||
pushed back onto the stack.</td>
|
||||
pushed back on to the stack.</td>
|
||||
</tr>
|
||||
<tr><td> -- </td>
|
||||
<td>DECR</td>
|
||||
<td>w -- w-1</td>
|
||||
<td>One value is popped off the stack. It is decremented by one and then
|
||||
pushed back onto the stack.</td>
|
||||
pushed back on to the stack.</td>
|
||||
</tr>
|
||||
<tr><td>MIN</td>
|
||||
<td>MIN</td>
|
||||
<td>w1 w2 -- (w2<w1?w2:w1)</td>
|
||||
<td>Two values are popped off the stack. The larger one is pushed back
|
||||
onto the stack.</td>
|
||||
on to the stack.</td>
|
||||
</tr>
|
||||
<tr><td>MAX</td>
|
||||
<td>MAX</td>
|
||||
<td>w1 w2 -- (w2>w1?w2:w1)</td>
|
||||
<td>Two values are popped off the stack. The larger value is pushed back
|
||||
onto the stack.</td>
|
||||
on to the stack.</td>
|
||||
</tr>
|
||||
<tr><td colspan="4">STACK MANIPULATION OPERATIONS</td></tr>
|
||||
<tr><td>Word</td><td>Name</td><td>Operation</td><td>Description</td></tr>
|
||||
@@ -703,13 +703,13 @@ using the following construction:</p>
|
||||
<tr><td>DUP</td>
|
||||
<td>DUP</td>
|
||||
<td>w1 -- w1 w1</td>
|
||||
<td>One value is popped off the stack. That value is then pushed onto
|
||||
the stack twice to duplicate the top stack vaue.</td>
|
||||
<td>One value is popped off the stack. That value is then pushed on to
|
||||
the stack twice to duplicate the top stack value.</td>
|
||||
</tr>
|
||||
<tr><td>DUP2</td>
|
||||
<td>DUP2</td>
|
||||
<td>w1 w2 -- w1 w2 w1 w2</td>
|
||||
<td>The top two values on the stack are duplicated. That is, two vaues
|
||||
<td>The top two values on the stack are duplicated. That is, two values
|
||||
are popped off the stack. They are alternately pushed back on the
|
||||
stack twice each.</td>
|
||||
</tr>
|
||||
@@ -717,7 +717,7 @@ using the following construction:</p>
|
||||
<td>SWAP</td>
|
||||
<td>w1 w2 -- w2 w1</td>
|
||||
<td>The top two stack items are reversed in their order. That is, two
|
||||
values are popped off the stack and pushed back onto the stack in
|
||||
values are popped off the stack and pushed back on to the stack in
|
||||
the opposite order they were popped.</td>
|
||||
</tr>
|
||||
<tr><td>SWAP2</td>
|
||||
@@ -725,27 +725,27 @@ using the following construction:</p>
|
||||
<td>w1 w2 w3 w4 -- w3 w4 w2 w1</td>
|
||||
<td>The top four stack items are swapped in pairs. That is, two values
|
||||
are popped and retained. Then, two more values are popped and retained.
|
||||
The values are pushed back onto the stack in the reverse order but
|
||||
The values are pushed back on to the stack in the reverse order but
|
||||
in pairs.</p>
|
||||
</tr>
|
||||
<tr><td>OVER</td>
|
||||
<td>OVER</td>
|
||||
<td>w1 w2-- w1 w2 w1</td>
|
||||
<td>Two values are popped from the stack. They are pushed back
|
||||
onto the stack in the order w1 w2 w1. This seems to cause the
|
||||
on to the stack in the order w1 w2 w1. This seems to cause the
|
||||
top stack element to be duplicated "over" the next value.</td>
|
||||
</tr>
|
||||
<tr><td>OVER2</td>
|
||||
<td>OVER2</td>
|
||||
<td>w1 w2 w3 w4 -- w1 w2 w3 w4 w1 w2</td>
|
||||
<td>The third and fourth values on the stack are replicated onto the
|
||||
<td>The third and fourth values on the stack are replicated on to the
|
||||
top of the stack</td>
|
||||
</tr>
|
||||
<tr><td>ROT</td>
|
||||
<td>ROT</td>
|
||||
<td>w1 w2 w3 -- w2 w3 w1</td>
|
||||
<td>The top three values are rotated. That is, three value are popped
|
||||
off the stack. They are pushed back onto the stack in the order
|
||||
off the stack. They are pushed back on to the stack in the order
|
||||
w1 w3 w2.</td>
|
||||
</tr>
|
||||
<tr><td>ROT2</td>
|
||||
@@ -822,7 +822,7 @@ using the following construction:</p>
|
||||
<td>One value is popped off the stack. The value is used as the size
|
||||
of a memory block to allocate. The size is in bytes, not words.
|
||||
The memory allocation is completed and the address of the memory
|
||||
block is pushed onto the stack.</td>
|
||||
block is pushed on to the stack.</td>
|
||||
</tr>
|
||||
<tr><td>FREE</td>
|
||||
<td>FREE</td>
|
||||
@@ -911,7 +911,7 @@ using the following construction:</p>
|
||||
<td>The boolean value on the top of the stack is examined. If it is non-zero then the
|
||||
"words..." between WHILE and END are executed. Execution then begins again at the WHILE where another
|
||||
boolean is popped off the stack. To prevent this operation from eating up the entire
|
||||
stack, you should push onto the stack (just before the END) a boolean value that indicates
|
||||
stack, you should push on to the stack (just before the END) a boolean value that indicates
|
||||
whether to terminate. Note that since booleans and integers can be coerced you can
|
||||
use the following "for loop" idiom:<br/>
|
||||
<code>(push count) WHILE (words...) -- END</code><br/>
|
||||
@@ -960,19 +960,19 @@ using the following construction:</p>
|
||||
<td>IN_STR</td>
|
||||
<td> -- s </td>
|
||||
<td>A string is read from the input via the scanf(3) format string " %as". The
|
||||
resulting string is pushed onto the stack.</td>
|
||||
resulting string is pushed on to the stack.</td>
|
||||
</tr>
|
||||
<tr><td><d</td>
|
||||
<td>IN_STR</td>
|
||||
<td> -- w </td>
|
||||
<td>An integer is read from the input via the scanf(3) format string " %d". The
|
||||
resulting value is pushed onto the stack</td>
|
||||
resulting value is pushed on to the stack</td>
|
||||
</tr>
|
||||
<tr><td><c</td>
|
||||
<td>IN_CHR</td>
|
||||
<td> -- w </td>
|
||||
<td>A single character is read from the input via the scanf(3) format string
|
||||
" %c". The value is converted to an integer and pushed onto the stack.</td>
|
||||
" %c". The value is converted to an integer and pushed on to the stack.</td>
|
||||
</tr>
|
||||
<tr><td>DUMP</td>
|
||||
<td>DUMP</td>
|
||||
@@ -989,9 +989,9 @@ using the following construction:</p>
|
||||
<p>The following fully documented program highlights many features of both
|
||||
the Stacker language and what is possible with LLVM. The program has two modes
|
||||
of operations. If you provide numeric arguments to the program, it checks to see
|
||||
if those arguments are prime numbers, prints out the results. Without any
|
||||
aruments, the program prints out any prime numbers it finds between 1 and one
|
||||
million (there's a log of them!). The source code comments below tell the
|
||||
if those arguments are prime numbers and prints out the results. Without any
|
||||
arguments, the program prints out any prime numbers it finds between 1 and one
|
||||
million (there's a lot of them!). The source code comments below tell the
|
||||
remainder of the story.
|
||||
</p>
|
||||
</div>
|
||||
@@ -1015,7 +1015,7 @@ remainder of the story.
|
||||
: exit_loop FALSE;
|
||||
|
||||
################################################################################
|
||||
# This definition tryies an actual division of a candidate prime number. It
|
||||
# This definition tries an actual division of a candidate prime number. It
|
||||
# determines whether the division loop on this candidate should continue or
|
||||
# not.
|
||||
# STACK<:
|
||||
@@ -1075,7 +1075,7 @@ remainder of the story.
|
||||
# STACK<:
|
||||
# p - the prime number to check
|
||||
# STACK>:
|
||||
# yn - boolean indiating if its a prime or not
|
||||
# yn - boolean indicating if its a prime or not
|
||||
# p - the prime number checked
|
||||
################################################################################
|
||||
: try_harder
|
||||
@@ -1248,7 +1248,7 @@ remainder of the story.
|
||||
under the LLVM "projects" directory. You will need to obtain the LLVM sources
|
||||
to find it (either via anonymous CVS or a tarball. See the
|
||||
<a href="GettingStarted.html">Getting Started</a> document).</p>
|
||||
<p>Under the "projects" directory there is a directory named "stacker". That
|
||||
<p>Under the "projects" directory there is a directory named "Stacker". That
|
||||
directory contains everything, as follows:</p>
|
||||
<ul>
|
||||
<li><em>lib</em> - contains most of the source code
|
||||
@@ -1301,7 +1301,7 @@ directory contains everything, as follows:</p>
|
||||
definitions, the ROLL word is not implemented. This word was left out of
|
||||
Stacker on purpose so that it can be an exercise for the student. The exercise
|
||||
is to implement the ROLL functionality (in your own workspace) and build a test
|
||||
program for it. If you can implement ROLL you understand Stacker and probably
|
||||
program for it. If you can implement ROLL, you understand Stacker and probably
|
||||
a fair amount about LLVM since this is one of the more complicated Stacker
|
||||
operations. The work will almost be completely limited to the
|
||||
<a href="#compiler">compiler</a>.
|
||||
@@ -1326,7 +1326,7 @@ interested, here are some things that could be implemented better:</p>
|
||||
emitted currently is somewhat wasteful. It gets cleaned up a lot by existing
|
||||
passes but more could be done.</li>
|
||||
<li>Add -O -O1 -O2 and -O3 optimization switches to the compiler driver to
|
||||
allow LLVM optimization without using "opt"</li>
|
||||
allow LLVM optimization without using "opt."</li>
|
||||
<li>Make the compiler driver use the LLVM linking facilities (with IPO) before
|
||||
depending on GCC to do the final link.</li>
|
||||
<li>Clean up parsing. It doesn't handle errors very well.</li>
|
||||
|
||||
@@ -1,69 +0,0 @@
|
||||
//===-- Support/Lock.h - Platform-agnostic mutual exclusion -----*- C++ -*-===//
|
||||
//
|
||||
// The LLVM Compiler Infrastructure
|
||||
//
|
||||
// This file was developed by the LLVM research group and is distributed under
|
||||
// the University of Illinois Open Source License. See LICENSE.TXT for details.
|
||||
//
|
||||
//===----------------------------------------------------------------------===//
|
||||
//
|
||||
// This file contains classes that implement locks (mutual exclusion
|
||||
// variables) in a platform-agnostic way. Basically the user should
|
||||
// just call Lock::create() to get a Lock object of the correct sort
|
||||
// for the current platform, and use its acquire() and release()
|
||||
// methods, or a LockHolder, to protect critical sections of code for
|
||||
// thread-safety.
|
||||
//
|
||||
//===----------------------------------------------------------------------===//
|
||||
|
||||
#ifndef SUPPORT_LOCK_H
|
||||
#define SUPPORT_LOCK_H
|
||||
|
||||
#include <pthread.h>
|
||||
#include <cstdlib>
|
||||
|
||||
namespace llvm {
|
||||
|
||||
/// Lock - Abstract class that provides mutual exclusion (also known
|
||||
/// as a mutex.)
|
||||
///
|
||||
class Lock {
|
||||
protected:
|
||||
virtual ~Lock() {} // Derive from me
|
||||
public:
|
||||
virtual void acquire () { abort (); }
|
||||
virtual void release () { abort (); }
|
||||
|
||||
/// create - Static method that returns a Lock of the correct class
|
||||
/// for the current host OS.
|
||||
///
|
||||
static Lock create ();
|
||||
};
|
||||
|
||||
/// POSIXLock - Specialization of Lock class implemented using
|
||||
/// pthread_mutex_t objects.
|
||||
///
|
||||
class POSIXLock : public Lock {
|
||||
pthread_mutex_t mutex;
|
||||
public:
|
||||
POSIXLock () { pthread_mutex_init (&mutex, 0); }
|
||||
virtual ~POSIXLock () { pthread_mutex_destroy (&mutex); }
|
||||
virtual void acquire () { pthread_mutex_lock (&mutex); }
|
||||
virtual void release () { pthread_mutex_unlock (&mutex); }
|
||||
};
|
||||
|
||||
/// LockHolder - Instances of this class acquire a given Lock when
|
||||
/// constructed and hold that lock until destruction. Uncle Bjarne
|
||||
/// says, "Resource acquisition is allocation." Or is it the other way
|
||||
/// around? I never can remember.
|
||||
///
|
||||
class LockHolder {
|
||||
Lock &L;
|
||||
public:
|
||||
LockHolder (Lock &_L) : L (_L) { L.acquire (); }
|
||||
~LockHolder () { L.release (); }
|
||||
};
|
||||
|
||||
} // end namespace llvm
|
||||
|
||||
#endif // SUPPORT_LOCK_H
|
||||
@@ -1,24 +0,0 @@
|
||||
//===-- Support/Lock.cpp - Platform-agnostic mutual exclusion -------------===//
|
||||
//
|
||||
// The LLVM Compiler Infrastructure
|
||||
//
|
||||
// This file was developed by the LLVM research group and is distributed under
|
||||
// the University of Illinois Open Source License. See LICENSE.TXT for details.
|
||||
//
|
||||
//===----------------------------------------------------------------------===//
|
||||
//
|
||||
// Implementation of various methods supporting platform-agnostic lock
|
||||
// abstraction. See Support/Lock.h for details.
|
||||
//
|
||||
//===----------------------------------------------------------------------===//
|
||||
|
||||
#include "Support/Lock.h"
|
||||
|
||||
using namespace llvm;
|
||||
|
||||
Lock Lock::create () {
|
||||
// Currently we only support creating POSIX pthread_mutex_t locks.
|
||||
// In the future we might want to construct different kinds of locks
|
||||
// based on what OS is running.
|
||||
return POSIXLock ();
|
||||
}
|
||||
@@ -26,6 +26,7 @@
|
||||
#include "Support/Debug.h"
|
||||
#include "Support/Statistic.h"
|
||||
#include "Support/STLExtras.h"
|
||||
#include <algorithm>
|
||||
using namespace llvm;
|
||||
|
||||
namespace {
|
||||
@@ -206,6 +207,14 @@ static bool TransformLoop(LoopInfo *Loops, Loop *Loop) {
|
||||
PHIOps.insert(PHIOps.end(), MaybeDead->op_begin(),
|
||||
MaybeDead->op_end());
|
||||
MaybeDead->getParent()->getInstList().erase(MaybeDead);
|
||||
|
||||
// Erase any duplicates entries in the PHIOps list.
|
||||
std::vector<Value*>::iterator It =
|
||||
std::find(PHIOps.begin(), PHIOps.end(), MaybeDead);
|
||||
while (It != PHIOps.end()) {
|
||||
PHIOps.erase(It);
|
||||
It = std::find(PHIOps.begin(), PHIOps.end(), MaybeDead);
|
||||
}
|
||||
|
||||
// Erasing the instruction could invalidate the AfterPHI iterator!
|
||||
AfterPHIIt = Header->begin();
|
||||
|
||||
@@ -1,9 +1,6 @@
|
||||
; global_ctors/global_dtors terminator: this is used to add a terminating null
|
||||
; value to the initialization list.
|
||||
|
||||
target endian = little
|
||||
target pointersize = 32
|
||||
|
||||
%struct..TorRec = type { int, void ()* }
|
||||
|
||||
%llvm.global_ctors = appending global [1 x %struct..TorRec] [
|
||||
|
||||
@@ -0,0 +1,22 @@
|
||||
void %_ZN17CoinFactorization7cleanupEv() {
|
||||
entry:
|
||||
br bool false, label %loopexit.14, label %cond_continue.3
|
||||
|
||||
cond_continue.3: ; preds = %entry
|
||||
ret void
|
||||
|
||||
loopexit.14: ; preds = %entry
|
||||
%tmp.738 = sub int 0, 0 ; <int> [#uses=1]
|
||||
br bool false, label %no_exit.15.preheader, label %loopexit.15
|
||||
|
||||
no_exit.15.preheader: ; preds = %loopexit.14
|
||||
br label %no_exit.15
|
||||
|
||||
no_exit.15: ; preds = %no_exit.15.preheader, %no_exit.15
|
||||
%highC.0 = phi int [ %tmp.738, %no_exit.15.preheader ], [ %dec.0, %no_exit.15 ] ; <int> [#uses=1]
|
||||
%dec.0 = add int %highC.0, -1 ; <int> [#uses=1]
|
||||
br bool false, label %no_exit.15, label %loopexit.15
|
||||
|
||||
loopexit.15: ; preds = %loopexit.14, %no_exit.15
|
||||
ret void
|
||||
}
|
||||
Reference in New Issue
Block a user