mirror of
https://github.com/c64scene-ar/llvm-6502.git
synced 2025-04-13 15:37:24 +00:00
Merged in RELEASE_11.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10516 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
parent
a71e05acdd
commit
d000e1dc2f
@ -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
configure
vendored
18
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>
|
||||
|
@ -18,7 +18,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 +29,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 +42,10 @@
|
||||
|
||||
<p>This document contains the release notes for the LLVM compiler
|
||||
infrastructure, release 1.2. 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.2/">LLVM 1.2 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
|
||||
@ -70,8 +69,7 @@ href="http://llvm.cs.uiuc.edu/releases/">releases page</a>.</p>
|
||||
|
||||
<div class="doc_text">
|
||||
|
||||
<p>This is the third public release of the LLVM compiler infrastructure. OTHER
|
||||
OVERVIEW STUFF HERE.
|
||||
<p>This is the third public release of the LLVM compiler infrastructure.
|
||||
</p>
|
||||
|
||||
<p>At this time, LLVM is known to correctly compile and run all non-unwinding C
|
||||
@ -82,10 +80,10 @@ received much less testing than the C front-end.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The LLVM native code generators are very stable, but do not currently support
|
||||
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 does support these programs however, so you can
|
||||
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>
|
||||
@ -164,11 +162,11 @@ management functions in libc runtime to allow them to be overriden</a></li>
|
||||
<p>LLVM has been extensively tested on Intel and AMD machines running Red
|
||||
Hat Linux and FreeBSD. It has also 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>
|
||||
@ -184,7 +182,7 @@ 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. 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
|
||||
href="http://llvm.cs.uiuc.edu/bugs/">LLVM bug database</a> and submit a bug if
|
||||
there isn't already one.</p>
|
||||
|
||||
</div>
|
||||
@ -219,6 +217,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>
|
||||
@ -232,9 +242,7 @@ more than 256 elements</a>.</li>
|
||||
<div class="doc_subsubsection">Bugs</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>
|
||||
@ -244,8 +252,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>
|
||||
|
||||
<!-- _______________________________________________________________________ -->
|
||||
@ -277,11 +304,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>
|
||||
@ -294,7 +321,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>
|
||||
@ -304,7 +331,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>,
|
||||
@ -363,7 +390,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>
|
||||
@ -395,7 +423,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>
|
||||
@ -411,9 +439,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>
|
||||
|
||||
<!-- _______________________________________________________________________ -->
|
||||
@ -433,7 +466,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
|
||||
@ -483,6 +516,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>
|
||||
@ -522,7 +560,7 @@ 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
|
||||
|
@ -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>
|
||||
<!-- ======================================================================= -->
|
||||
@ -77,11 +77,11 @@ language running 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
|
||||
@ -95,11 +95,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
|
||||
@ -123,7 +123,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
|
||||
@ -201,7 +201,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
|
||||
@ -262,7 +262,7 @@ 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 is also of type <code>Value</code>). To create
|
||||
@ -271,7 +271,8 @@ arguments the blocks to branch to and the condition to branch on. The
|
||||
<code>BasicBlock</code> objects 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 <code>exit_bb</code> block which is returned
|
||||
<code>handle_if</code>, we create an <code>exit_bb</code> block which is
|
||||
returned
|
||||
to the caller. Note that the <code>exit_bb</code> block is used as the
|
||||
terminator for both the <code>then_bb</code> and the <code>else_bb</code>
|
||||
blocks. This guarantees that no matter what else <code>handle_if</code>
|
||||
@ -286,7 +287,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>
|
||||
@ -295,17 +296,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>
|
||||
@ -322,13 +323,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 strongly typed. Everything has a type.
|
||||
The "type" of the global variable is [24 x int]*. That is, its
|
||||
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>
|
||||
<!-- ======================================================================= -->
|
||||
@ -337,7 +338,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 firm 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
|
||||
@ -346,10 +347,10 @@ carefully. Then, read it again.<p>
|
||||
<p>Here are some handy tips that I discovered along the way:</p>
|
||||
<ul>
|
||||
<li><em>Unitialized means external.</em> 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>
|
||||
module and can be used by that module, but it is not defined by that module.</li>
|
||||
<li><em>Setting an initializer changes a global' linkage type.</em> 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() method to
|
||||
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><em>Appending linkage can keep track of things.</em> Appending linkage can
|
||||
@ -368,7 +369,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
|
||||
@ -385,14 +386,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
|
||||
@ -412,9 +413,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>
|
||||
@ -435,12 +436,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>
|
||||
@ -470,21 +471,21 @@ 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
|
||||
its elements around.<br/> The words are: DROP DROP2 NIP NIP2 DUP DUP2
|
||||
SWAP SWAP2 OVER OVER2 ROT ROT2 RROT RROT2 TUCK TUCK2 PICK SELECT ROLL</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>
|
||||
@ -566,12 +567,12 @@ using the following construction:</p>
|
||||
<tr><td style="border: 2px solid blue">FALSE</td>
|
||||
<td style="border: 2px solid blue">FALSE</td>
|
||||
<td style="border: 2px solid blue"> -- b</td>
|
||||
<td style="border: 2px solid blue">The boolean value FALSE (0) is pushed onto the stack.</td>
|
||||
<td style="border: 2px solid blue">The boolean value FALSE (0) is pushed on to the stack.</td>
|
||||
</tr>
|
||||
<tr><td style="border: 2px solid blue">TRUE</td>
|
||||
<td style="border: 2px solid blue">TRUE</td>
|
||||
<td style="border: 2px solid blue"> -- b</td>
|
||||
<td style="border: 2px solid blue">The boolean value TRUE (-1) is pushed onto the stack.</td>
|
||||
<td style="border: 2px solid blue">The boolean value TRUE (-1) is pushed on to the stack.</td>
|
||||
</tr>
|
||||
<tr><td colspan="4"><b>BITWISE OPERATORS</b></td></tr>
|
||||
<tr>
|
||||
@ -626,75 +627,75 @@ using the following construction:</p>
|
||||
<td style="border: 2px solid blue">ABS</td>
|
||||
<td style="border: 2px solid blue">w -- |w|</td>
|
||||
<td style="border: 2px solid blue">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 style="border: 2px solid blue">NEG</td>
|
||||
<td style="border: 2px solid blue">NEG</td>
|
||||
<td style="border: 2px solid blue">w -- -w</td>
|
||||
<td style="border: 2px solid blue">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 style="border: 2px solid blue"> + </td>
|
||||
<td style="border: 2px solid blue">ADD</td>
|
||||
<td style="border: 2px solid blue">w1 w2 -- w2+w1</td>
|
||||
<td style="border: 2px solid blue">Two values are popped off the stack. Their sum is pushed back
|
||||
onto the stack</td>
|
||||
on to the stack</td>
|
||||
</tr>
|
||||
<tr><td style="border: 2px solid blue"> - </td>
|
||||
<td style="border: 2px solid blue">SUB</td>
|
||||
<td style="border: 2px solid blue">w1 w2 -- w2-w1</td>
|
||||
<td style="border: 2px solid blue">Two values are popped off the stack. Their difference is pushed back
|
||||
onto the stack</td>
|
||||
on to the stack</td>
|
||||
</tr>
|
||||
<tr><td style="border: 2px solid blue"> * </td>
|
||||
<td style="border: 2px solid blue">MUL</td>
|
||||
<td style="border: 2px solid blue">w1 w2 -- w2*w1</td>
|
||||
<td style="border: 2px solid blue">Two values are popped off the stack. Their product is pushed back
|
||||
onto the stack</td>
|
||||
on to the stack</td>
|
||||
</tr>
|
||||
<tr><td style="border: 2px solid blue"> / </td>
|
||||
<td style="border: 2px solid blue">DIV</td>
|
||||
<td style="border: 2px solid blue">w1 w2 -- w2/w1</td>
|
||||
<td style="border: 2px solid blue">Two values are popped off the stack. Their quotient is pushed back
|
||||
onto the stack</td>
|
||||
on to the stack</td>
|
||||
</tr>
|
||||
<tr><td style="border: 2px solid blue">MOD</td>
|
||||
<td style="border: 2px solid blue">MOD</td>
|
||||
<td style="border: 2px solid blue">w1 w2 -- w2%w1</td>
|
||||
<td style="border: 2px solid blue">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 style="border: 2px solid blue"> */ </td>
|
||||
<td style="border: 2px solid blue">STAR_SLAH</td>
|
||||
<td style="border: 2px solid blue">w1 w2 w3 -- (w3*w2)/w1</td>
|
||||
<td style="border: 2px solid blue">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 style="border: 2px solid blue"> ++ </td>
|
||||
<td style="border: 2px solid blue">INCR</td>
|
||||
<td style="border: 2px solid blue">w -- w+1</td>
|
||||
<td style="border: 2px solid blue">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 style="border: 2px solid blue"> -- </td>
|
||||
<td style="border: 2px solid blue">DECR</td>
|
||||
<td style="border: 2px solid blue">w -- w-1</td>
|
||||
<td style="border: 2px solid blue">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 style="border: 2px solid blue">MIN</td>
|
||||
<td style="border: 2px solid blue">MIN</td>
|
||||
<td style="border: 2px solid blue">w1 w2 -- (w2<w1?w2:w1)</td>
|
||||
<td style="border: 2px solid blue">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 style="border: 2px solid blue">MAX</td>
|
||||
<td style="border: 2px solid blue">MAX</td>
|
||||
<td style="border: 2px solid blue">w1 w2 -- (w2>w1?w2:w1)</td>
|
||||
<td style="border: 2px solid blue">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"><b>STACK MANIPULATION OPERATORS</b></td></tr>
|
||||
<tr>
|
||||
@ -730,7 +731,7 @@ using the following construction:</p>
|
||||
<tr><td style="border: 2px solid blue">DUP</td>
|
||||
<td style="border: 2px solid blue">DUP</td>
|
||||
<td style="border: 2px solid blue">w1 -- w1 w1</td>
|
||||
<td style="border: 2px solid blue">One value is popped off the stack. That value is then pushed onto
|
||||
<td style="border: 2px solid blue">One value is popped off the stack. That value is then pushed on to
|
||||
the stack twice to duplicate the top stack vaue.</td>
|
||||
</tr>
|
||||
<tr><td style="border: 2px solid blue">DUP2</td>
|
||||
@ -744,7 +745,7 @@ using the following construction:</p>
|
||||
<td style="border: 2px solid blue">SWAP</td>
|
||||
<td style="border: 2px solid blue">w1 w2 -- w2 w1</td>
|
||||
<td style="border: 2px solid blue">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 style="border: 2px solid blue">SWAP2</td>
|
||||
@ -752,27 +753,27 @@ using the following construction:</p>
|
||||
<td style="border: 2px solid blue">w1 w2 w3 w4 -- w3 w4 w2 w1</td>
|
||||
<td style="border: 2px solid blue">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 style="border: 2px solid blue">OVER</td>
|
||||
<td style="border: 2px solid blue">OVER</td>
|
||||
<td style="border: 2px solid blue">w1 w2-- w1 w2 w1</td>
|
||||
<td style="border: 2px solid blue">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 style="border: 2px solid blue">OVER2</td>
|
||||
<td style="border: 2px solid blue">OVER2</td>
|
||||
<td style="border: 2px solid blue">w1 w2 w3 w4 -- w1 w2 w3 w4 w1 w2</td>
|
||||
<td style="border: 2px solid blue">The third and fourth values on the stack are replicated onto the
|
||||
<td style="border: 2px solid blue">The third and fourth values on the stack are replicated on to the
|
||||
top of the stack</td>
|
||||
</tr>
|
||||
<tr><td style="border: 2px solid blue">ROT</td>
|
||||
<td style="border: 2px solid blue">ROT</td>
|
||||
<td style="border: 2px solid blue">w1 w2 w3 -- w2 w3 w1</td>
|
||||
<td style="border: 2px solid blue">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 style="border: 2px solid blue">ROT2</td>
|
||||
@ -854,7 +855,7 @@ using the following construction:</p>
|
||||
<td style="border: 2px solid blue">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 style="border: 2px solid blue">FREE</td>
|
||||
<td style="border: 2px solid blue">FREE</td>
|
||||
@ -948,7 +949,7 @@ using the following construction:</p>
|
||||
<td style="border: 2px solid blue">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/>
|
||||
@ -1002,19 +1003,19 @@ using the following construction:</p>
|
||||
<td style="border: 2px solid blue">IN_STR</td>
|
||||
<td style="border: 2px solid blue"> -- s </td>
|
||||
<td style="border: 2px solid blue">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 style="border: 2px solid blue"><d</td>
|
||||
<td style="border: 2px solid blue">IN_STR</td>
|
||||
<td style="border: 2px solid blue"> -- w </td>
|
||||
<td style="border: 2px solid blue">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 style="border: 2px solid blue"><c</td>
|
||||
<td style="border: 2px solid blue">IN_CHR</td>
|
||||
<td style="border: 2px solid blue"> -- w </td>
|
||||
<td style="border: 2px solid blue">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 style="border: 2px solid blue">DUMP</td>
|
||||
<td style="border: 2px solid blue">DUMP</td>
|
||||
@ -1030,9 +1031,9 @@ using the following construction:</p>
|
||||
<div class="doc_text">
|
||||
<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
|
||||
of operation. If you provide numeric arguments to the program, it checks to see
|
||||
if those arguments are prime numbers and prints out the results. Without any
|
||||
aruments, the program prints out any prime numbers it finds between 1 and one
|
||||
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>
|
||||
@ -1057,7 +1058,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<:
|
||||
@ -1117,7 +1118,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
|
||||
@ -1290,7 +1291,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
|
||||
@ -1343,7 +1344,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>.
|
||||
@ -1374,7 +1375,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>
|
||||
|
@ -15,19 +15,19 @@
|
||||
//===----------------------------------------------------------------------===//
|
||||
|
||||
#include "llvm/Transforms/Scalar.h"
|
||||
#include "llvm/Constants.h"
|
||||
#include "llvm/Type.h"
|
||||
#include "llvm/iPHINode.h"
|
||||
#include "llvm/iOther.h"
|
||||
#include "llvm/Analysis/InductionVariable.h"
|
||||
#include "llvm/Analysis/LoopInfo.h"
|
||||
#include "llvm/iPHINode.h"
|
||||
#include "llvm/iOther.h"
|
||||
#include "llvm/Type.h"
|
||||
#include "llvm/Constants.h"
|
||||
#include "llvm/Support/CFG.h"
|
||||
#include "llvm/Transforms/Utils/Local.h"
|
||||
#include "Support/Debug.h"
|
||||
#include "Support/Statistic.h"
|
||||
#include "Support/STLExtras.h"
|
||||
#include <algorithm>
|
||||
using namespace llvm;
|
||||
|
||||
namespace llvm {
|
||||
|
||||
namespace {
|
||||
Statistic<> NumRemoved ("indvars", "Number of aux indvars removed");
|
||||
@ -141,8 +141,6 @@ static bool TransformLoop(LoopInfo *Loops, Loop *Loop) {
|
||||
|
||||
DEBUG(IV->print(std::cerr));
|
||||
|
||||
while (isa<PHINode>(AfterPHIIt)) ++AfterPHIIt;
|
||||
|
||||
// Don't do math with pointers...
|
||||
const Type *IVTy = IV->Phi->getType();
|
||||
if (isa<PointerType>(IVTy)) IVTy = Type::ULongTy;
|
||||
@ -188,12 +186,6 @@ static bool TransformLoop(LoopInfo *Loops, Loop *Loop) {
|
||||
IV->Phi->setName("");
|
||||
Val->setName(OldName);
|
||||
|
||||
// Get the incoming values used by the PHI node
|
||||
std::vector<Value*> PHIOps;
|
||||
PHIOps.reserve(IV->Phi->getNumIncomingValues());
|
||||
for (unsigned i = 0, e = IV->Phi->getNumIncomingValues(); i != e; ++i)
|
||||
PHIOps.push_back(IV->Phi->getIncomingValue(i));
|
||||
|
||||
// Delete the old, now unused, phi node...
|
||||
Header->getInstList().erase(IV->Phi);
|
||||
|
||||
@ -250,7 +242,8 @@ namespace {
|
||||
"Canonicalize Induction Variables");
|
||||
}
|
||||
|
||||
Pass *llvm::createIndVarSimplifyPass() {
|
||||
Pass *createIndVarSimplifyPass() {
|
||||
return new InductionVariableSimplify();
|
||||
}
|
||||
|
||||
} // End llvm namespace
|
||||
|
@ -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] [
|
||||
|
Loading…
x
Reference in New Issue
Block a user