[llvm-commits] [llvm] r150677 - /llvm/trunk/docs/ReleaseNotes.html

[Bill Wendling]

Author: void
Date: Thu Feb 16 04:23:43 2012
New Revision: 150677

URL: http://llvm.org/viewvc/llvm-project?rev=150677&view=rev
Log:
Add blurb about module flags and reformat a bit.

Modified:
    llvm/trunk/docs/ReleaseNotes.html

Modified: llvm/trunk/docs/ReleaseNotes.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/ReleaseNotes.html?rev=150677&r1=150676&r2=150677&view=diff
==============================================================================
--- llvm/trunk/docs/ReleaseNotes.html (original)
+++ llvm/trunk/docs/ReleaseNotes.html Thu Feb 16 04:23:43 2012
@@ -286,9 +286,8 @@
   <ul>
     <li>IR support for half float</li>
     <li>IR support for vectors of pointers, including vector GEPs.</li>
-    <li>The <tt>unwind</tt> instruction is now gone. With the introduction of
-        the new exception handling system in LLVM 3.0, the <tt>unwind</tt>
-        instruction became obsolete.</li>
+    <li>Module flags have been introduced. They convey information about the
+        module as a whole to LLVM subsystems.</li>
     <li>....</li>
   </ul>
 </div>
@@ -337,12 +336,12 @@
 
 <div>
 
-<p>We have changed the way that the Type Legalizer legalizes vectors.
-	The type legalizer now attempts to promote integer elements.
-	This enabled the implementation of vector-select.
-	Additionally, we see a performance boost on workloads which use vectors of chars and shorts, since they are now promoted
-	to 32-bit types, which are better supported by the SIMD instruction set.
-	Floating point types are still widened as before.</p>
+<p>We have changed the way that the Type Legalizer legalizes vectors. The type
+   legalizer now attempts to promote integer elements.  This enabled the
+   implementation of vector-select.  Additionally, we see a performance boost on
+   workloads which use vectors of chars and shorts, since they are now promoted
+   to 32-bit types, which are better supported by the SIMD instruction set.
+   Floating point types are still widened as before.</p>
 
 
 <p>We have put a significant amount of work into the code generator
@@ -351,18 +350,19 @@
 
 <ul>
   <li>TableGen can now synthesize register classes that are only needed to
-  represent combinations of constraints from instructions and sub-registers.
-  The synthetic register classes inherit most of their properties form their
-  closest user-defined super-class.</li>
+      represent combinations of constraints from instructions and sub-registers.
+      The synthetic register classes inherit most of their properties form their
+      closest user-defined super-class.</li>
   <li><code>MachineRegisterInfo</code> now allows the reserved registers to be
-  frozen when register allocation starts.  Target hooks should use the
-  <code>MRI->canReserveReg(FramePtr)</code> method to avoid accidentally
-  disabling frame pointer elimination during register allocation.</li>
+      frozen when register allocation starts.  Target hooks should use the
+      <code>MRI->canReserveReg(FramePtr)</code> method to avoid accidentally
+      disabling frame pointer elimination during register allocation.</li>
   <li>A new kind of <code>MachineOperand</code> provides a compact
-  representation of large clobber lists on call instructions.  The register
-  mask operand references a bit mask of preserved registers. Everything else is
-  clobbered.</li>
+      representation of large clobber lists on call instructions.  The register
+      mask operand references a bit mask of preserved registers. Everything else
+      is clobbered.</li>
 </ul>
+
 </div>
 
 <!--=========================================================================-->
@@ -439,9 +439,12 @@
    from the previous release.</p>
 
 <ul>
-<li>LLVM 3.1 removes support for reading LLVM 2.9 bitcode files.  Going forward,
-    we aim for all future versions of LLVM to read bitcode files and .ll files
-    produced by LLVM 3.0 and later.</li>
+  <li>LLVM 3.1 removes support for reading LLVM 2.9 bitcode files. Going
+      forward, we aim for all future versions of LLVM to read bitcode files and
+      <tt>.ll</tt> files produced by LLVM 3.0 and later.</li>
+  <li>The <tt>unwind</tt> instruction is now gone. With the introduction of the
+      new exception handling system in LLVM 3.0, the <tt>unwind</tt> instruction
+      became obsolete.</li>
   <li>....</li>
 </ul>