several edits
authorChris Lattner <sabre@nondot.org>
Sun, 8 Jun 2008 22:59:35 +0000 (22:59 +0000)
committerChris Lattner <sabre@nondot.org>
Sun, 8 Jun 2008 22:59:35 +0000 (22:59 +0000)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52107 91177308-0d34-0410-b5e6-96231b3b80d8

docs/ReleaseNotes.html

index 402aa614c9845d6d1f550cd9b16f06bd7fa3ccb0..da797b5d49e3b3f066cb48d170b4e692d002433c 100644 (file)
@@ -195,6 +195,14 @@ bugs in C and Objective-C code.</p>
 </div>
 <!-- *********************************************************************** -->
 
+<div class="doc_text">
+
+<p>LLVM 2.3 includes a huge number of bug fixes, performance tweaks and minor
+improvements.  Some of the major improvements and new features are listed in
+this section.
+</p>
+</div>
+
 <!--=========================================================================-->
 <div class="doc_subsection">
 <a name="majorfeatures">Major New Features</a>
@@ -261,15 +269,20 @@ bugs in C and Objective-C code.</p>
 
 <div class="doc_text">
 
-<p>LLVM 2.3 fully supports the llvm-gcc 4.2 front-end.</p>
+<p>LLVM 2.3 fully supports the llvm-gcc 4.2 front-end, and includes support
+for the C, C++, Objective-C, Ada, and Fortran front-ends.</p>
 
-<p>llvm-gcc 4.2 includes numerous fixes to better support the Objective-C
-front-end.  Objective-C now works very well on Mac OS/X.</p>
+<p>
+<ul>
+<li>llvm-gcc 4.2 includes numerous fixes to better support the Objective-C
+front-end.  Objective-C now works very well on Mac OS/X.</li>
+
+<li>Fortran EQUIVALENCEs are now supported by the gfortran front-end.</li>
 
-<p>Fortran EQUIVALENCEs are now supported by the gfortran front-end.</p>
+<li>llvm-gcc 4.2 includes many other fixes which improve conformance with the
+relevant parts of the GCC testsuite.</li>
 
-<p>llvm-gcc 4.2 includes many other fixes which improve conformance with the
-relevant parts of the GCC testsuite.</p>
+</ul></p>
 
 </div>
 
@@ -283,16 +296,18 @@ relevant parts of the GCC testsuite.</p>
 <p>New features include:
 </p>
 
+<ul>
+<li>LLVM IR now directly represents "common" linkage, instead of representing it
+as a form of weak linkage.</li>
 
-Common linkage?
-
-Atomic operation support, Alpha, X86, X86-64, PowerPC. "__sync_synchronize", 
-"__sync_val_compare_and_swap", etc
+<li>LLVM IR now has support for atomic operations, and this functionality can
+be accessed through the llvm-gcc "__sync_synchronize",
+"__sync_val_compare_and_swap", and related builtins.  Support for atomics are
+available in the Alpha, X86, X86-64, and PowerPC backends.</li>
 
-<ul>
-<li>The C and Ocaml bindings have received additional improvements. The
-bindings now cover pass managers, several transformation passes, iteration
-over the LLVM IR, target data, and parameter attribute lists.</li>
+<li>The C and Ocaml bindings have extended to cover pass managers, several
+transformation passes, iteration over the LLVM IR, target data, and parameter
+attribute lists.</li>
 </ul>
   
 </div>
@@ -309,15 +324,18 @@ LLVM 2.3 optimizers support a few major enhancements:</p>
 
 <ul>
 
-<li>Loop index set splitting on by default.<p>
-This transformation hoists conditions from loop bodies and reduces loop's
-iteration space to improve performance. For example, <p>
+<li><p>Loop index set splitting on by default.
+This transformation hoists conditions from loop bodies and reduces a loop's
+iteration space to improve performance. For example,</p>
+
 <pre>
 for (i = LB; i &lt; UB; ++i)
   if (i &lt;= NV)
     LOOP_BODY
 </pre>
-is transformed into
+
+<p>is transformed into:</p>
+
 <pre>
 NUB = min(NV+1, UB)
 for (i = LB; i &lt; NUB; ++i)
@@ -325,7 +343,7 @@ for (i = LB; i &lt; NUB; ++i)
 </pre>
 </li>
 
-<li>LLVM includes a new <tt>memcpy</tt> optimization pass which removes
+<li>LLVM now includes a new <tt>memcpy</tt> optimization pass which removes
 dead <tt>memcpy</tt> calls, unneeded copies of aggregates, and performs
 return slot optimization.  The LLVM optimizer now notices long sequences of
 consecutive stores and merges them into <tt>memcpy</tt>'s where profitable.</li>
@@ -333,14 +351,12 @@ consecutive stores and merges them into <tt>memcpy</tt>'s where profitable.</li>
 <li>Alignment detection for vector memory references and for <tt>memcpy</tt> and
 <tt>memset</tt> is now more aggressive.</li> 
 
-<li>The aggressive dead code elimination (ADCE) optimization has been rewritten
+<li>The Aggressive Dead Code Elimination (ADCE) optimization has been rewritten
 to make it both faster and safer in the presence of code containing infinite
 loops.  Some of its prior functionality has been factored out into the loop
-deletion pass, which <em>is</em> safe for infinite loops.</li>
+deletion pass, which <em>is</em> safe for infinite loops.  The new ADCE pass is
+no longer based on control dependence, making it run faster.</li>
 
-<li>Several optimizations have been sped up, leading to faster code generation
-    with the same code quality.</li>
-    
 <li>The 'SimplifyLibCalls' pass, which optimizes calls to libc and libm
     functions for C-based languages, has been rewritten to be a FunctionPass
     instead a ModulePass.  This allows it to be run more often and to be
@@ -354,6 +370,10 @@ deletion pass, which <em>is</em> safe for infinite loops.</li>
     
 <li>Several corner case bugs which could lead to deleting volatile memory
     accesses have been fixed.</li>
+
+<li>Several optimizations have been sped up, leading to faster code generation
+    with the same code quality.</li>
+  
 </ul>
 
 </div>