</tr></table>
<ol>
- <li><a href="#intro">Instroduction</a>
+ <li><a href="#intro">Introduction</a>
<li><a href="#whatsnew">What's New?</a>
+ <li><a href="#portability">Portability and Supported Platforms</a>
<li><a href="#install-instructions">Installation Instructions</a>
<li><a href="#knownproblems">Known Problems</a>
<ul>
- <li><a href="#portability">Portability Problems</a>
+<!-- <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>
<!-- *********************************************************************** -->
This document contains the release notes for the LLVM compiler infrastructure,
-release 1.0. The most up-to-date version of this document can be found on the
-<a href="http://llvm.cs.uiuc.edu/releases/1.0/ReleaseNotes.html">LLVM web
-site</a>. Since this document may be updated after the release, it is best to
-read the copy hosted there.
+release 1.0. Here we describe how to install LLVM, as well as any known
+problems. The most up-to-date version of this document can be found on the <a
+href="http://llvm.cs.uiuc.edu/releases/1.0/">LLVM 1.0 web site</a>. If you are
+not reading this on the LLVM web pages, you should probably go there, because
+this document may be updated after the release.<p>
+
+For more information about LLVM, including information about potentially more
+current releases, please check out the <a href="http://llvm.cs.uiuc.edu">main
+web site</a>. If you have questions or comments, the <a
+href="http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVM developer's mailing
+list</a> is a good place to send them.<p>
<!-- *********************************************************************** -->
compiler, a C back-end, stable X86 and Sparc V9 static and JIT code generators,
as well as a large suite of scalar and interprocedural optimizations.<p>
+The default optimizer sequence used by the C/C++ front-ends is:<p>
+
+<ol>
+<li>Interprocedural dead code elimination (-globaldce)
+<li>Exception handling pruning (-prune-eh)
+<li>Function inlining (-inline)
+<li>Instruction combining (-instcombine)
+<li>Cast elimination (-raise)
+<li>Tail duplication (-tailduplicate)
+<li>CFG simplification (-simplifycfg)
+<li>Scalar replacement of aggregates (-scalarrepl)
+<li>Tail call elimination (-tailcallelim)
+<li>Instruction combining (-instcombine)
+<li>Reassociation (-reassociate)
+<li>Instruction combining (-instcombine)
+<li>CFG simplification (-simplifycfg)
+<li>Loop canonicalization (-loopsimplify)
+<li>Loop invariant code motion, with scalar promotion (-licm)
+<li>Global common subexpression elimination, with load elimination (-gcse)
+<li>Sparse conditional constant propagation (-sccp)
+<li>Instruction combining (-instcombine)
+<li>Induction variable canonicalization (-indvars)
+<li>Aggressive dead code elimination (-adce)
+<li>CFG simplication (-simplifycfg)
+<li>Dead type elimination (-deadtypeelim)
+<li>Global constant merging (-constmerge)
+</ol><p>
+
+At link-time, the following optimizations are run:<p>
+
+<ol>
+<li>Global constant merging (-constmerge)
+<li>[optional] Internalization [which marks most functions and global variables static] (-internalize)
+<li>Interprocedural dead argument elimination (-deadargelim)
+<li>Instruction combining (-instcombine)
+<li>CFG simplification (-simplifycfg)
+<li>Interprocedural dead code elimination (-globaldce)
+</ol><p>
+
+
TODO: Works on: SPEC CPU 2000<p>
-TODO: Works on: Olden/Ptrdist benchmarks
+TODO: Works on: Olden/Ptrdist benchmarks<p>
+
+The What's New section should give a bulletted list of what is
+included, perhaps a couple of lists (Stable, Beta).<p>
+
+It would be useful to give a pointer to a list of the available passes (at least
+for the standard compiler techniques).<p>
+
+
+<!-- *********************************************************************** -->
+</ul><table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0>
+<tr><td align=center><font color="#EEEEFF" size=+2 face="Georgia,Palatino"><b>
+<a name="portability">Portability and Supported Platforms
+</b></font></td></tr></table><ul>
+<!-- *********************************************************************** -->
+
+LLVM has only been extensively tested on ia32-linux and sparc-solaris machines.
+The core LLVM infrastructure uses "autoconf" for portability, so hopefully we
+work on more platforms than that. However, it is extremely likely that we
+missed something. We welcome portability patches and error messages.<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, so it is important to check the <a
-href="http://llvm.cs.uiuc.edu/releases/1.0/ReleaseNotes.html">web version</a> of
-this document for up-to-date information.
+sections.
<!-- _______________________________________________________________________ -->
+<!--
</ul><h4><a name="portability"><hr size=0>Portability Problems</h4><ul>
-
-LLVM has only been extensively tested on ia32-linux and sparc-solaris machines.
-The core LLVM infrastructure uses "autoconf" for portability, so hopefully we
-work on more platforms than that. However, it is extremely likely that we
-missed something. We welcome portability patches and error messages.<p>
+-->
<!-- _______________________________________________________________________ -->
<li>Inline assembly is not yet supported.<p>
<li>"long double" is transformed by the front-end into "double". There is no
- support for floating point data types of any size other than 32 and 64 bits.
+ support for floating point data types of any size other than 32 and 64 bits.
+ <p>
<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>
}
</pre><p>
-<li>The following unix system functionality has not been tested and may not work:
+<li>The following Unix system functionality has not been tested and may not work:
<ol>
<li><tt>sigsetjmp</tt>, <tt>siglongjmp</tt> - These are not turned into the
appropriate <tt>invoke</tt>/<tt>unwind</tt> instructions.
- These functions have not been tested.
</ol><p>
+<li>Bugs:<br>
+ <a href="http://llvm.cs.uiuc.edu/PR6">Oversized integer bitfields cause crash</a>.<br>
+ <a href="http://llvm.cs.uiuc.edu/PR9">LLVM needs explicit support for weak variables</a>.<br>
+<p>
+
<li>Although many GCC extensions are supported, some are not. In particular,
the following extensions are known to <b>not be</b> supported:
<ol>
<ol>
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html#Statement%20Exprs">Statement Exprs</a>: Putting statements and declarations inside expressions.
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Typeof.html#Typeof">Typeof</a>: <code>typeof</code>: referring to the type of an expression.
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Lvalues.html#Lvalues">Lvalues</a>: Using <code>?:</code>, <code>,</code> and casts in lvalues.
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Lvalues.html#Lvalues">Lvalues</a>: Using <code>?:</code>, "<code>,</code>" and casts in lvalues.
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Conditionals.html#Conditionals">Conditionals</a>: Omitting the middle operand of a <code>?:</code> expression.
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Long-Long.html#Long%20Long">Long Long</a>: Double-word integers.
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Complex.html#Complex">Complex</a>: Data types for complex numbers.
href="http://gcc.gnu.org/gcc-3.4/changes.html">GCC 3.4 release notes</a>.<p>
<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
+ 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
better than most compilers).<p>
-<li>The calling conventions and name mangling used by the LLVM C++ front-end do
- follow the <a href="http://www.codesourcery.com/cxx-abi">Itanium C++
- ABI</a>, and thus we should be binary compatible with native C++ code
- compiled with a recent GCC compiler. However, the exception handling
- mechanisms are very different, so they will not interact correctly.
+<li>The LLVM C++ front-end follows the <a
+ href="http://www.codesourcery.com/cxx-abi">Itanium C++ ABI</a>.
+ This document, which is not Itanium specific, specifies a standard for name
+ mangling, class layout, v-table layout, RTTI formats, and other C++
+ representation issues. Because we use this API, code generated by the LLVM
+ compilers should be binary compatible with machine code generated by other
+ Itanium ABI C++ compilers (such as G++, the Intel and HP compilers, etc).
+ <i>However</i>, the exception handling mechanism used by LLVM is very
+ different from the model used in the Itanium ABI, so <b>exceptions will not
+ interact correctly</b> .
+
+<li><a href="http://llvm.cs.uiuc.edu/PR11">Code for executing
+destructors when unwinding is not shared</a>.
+
<!-- _______________________________________________________________________ -->
</ul><h4><a name="x86-be"><hr size=0>Known problems with the X86 back-end</h4><ul>
-<li>The X86 code generator does not currently support the <tt>unwind</tt>
-instruction, so code that throws a C++ exception or calls the C <tt>longjmp</tt>
-function will abort.<p>
+<li>The X86 code generator <a
+href="http://llvm.cs.uiuc.edu/PR16">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.<p>
-<li>Some executables produced by LLC seem to intermittently crash (extremely
-infrequently). The cause of the problem has not been diagnosed, and does not
-affect the JIT.<p>
+<li><a href="http://llvm.cs.uiuc.edu/PR4">Some executables
+produced by LLC seem to intermittently crash (extremely infrequently)</a>. The
+
cause of the problem has not been diagnosed, and does not affect the JIT.<p>
<!-- _______________________________________________________________________ -->
</ul><h4><a name="sparc-be"><hr size=0>Known problems with the Sparc back-end</h4><ul>
-<li>The Sparc code generator does not currently support the <tt>invoke</tt> or
-<tt>unwind</tt> instructions, so code produced by the C++ front-end and C code
-that calls the <tt>setjmp</tt> or <tt>longjmp</tt> functions will not compile.
+<li>The Sparc code generator <a
+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.<p>
<!-- _______________________________________________________________________ -->
<li>Initializers for global variables that include floating point numbers may
not be initialized with exactly the right floating point number, if the number
is not accurately representable in decimal. This prevents the Olden "power"
-benchmark from producing exactly the right results with the C backend.<p>
+benchmark from producing exactly the right results with the C back
-end.<p>
<li>The code produces by the C back-end has only been tested with the Sun CC and
GCC compilers. It is possible that it will have to be adjusted to support other
<hr><font size-1>
-<address>By: <a href="mailto:sabre@nondot.org">Chris Lattner</a></address>
+Maintained By: <a href="http://llvm.cs.uiuc.edu/">The LLVM Team</a><br>
<!-- Created: Wed Oct 1 17:38:54 CDT 2003 -->
<!-- hhmts start -->
-Last modified: Thu Oct 2 00:06:58 CDT 2003
+Last modified: Sun Oct 12 16:51:06 CDT 2003
<!-- hhmts end -->
</body></html>
projects / oota-llvm.git / blobdiff