From 190ec9b9c1f492f3291d85253df8bdae6032ba81 Mon Sep 17 00:00:00 2001
From: Bill Wendling <isanbard@gmail.com>
Date: Thu, 16 Feb 2012 10:23:43 +0000
Subject: Add blurb about module flags and reformat a bit.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@150677 91177308-0d34-0410-b5e6-96231b3b80d8
---
 docs/ReleaseNotes.html | 45 ++++++++++++++++++++++++---------------------
 1 file changed, 24 insertions(+), 21 deletions(-)

diff --git a/docs/ReleaseNotes.html b/docs/ReleaseNotes.html
index 6d08b4e..c284b9c 100644
--- a/docs/ReleaseNotes.html
+++ b/docs/ReleaseNotes.html
@@ -286,9 +286,8 @@ Release Notes</a>.</h1>
   <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 @@ Release Notes</a>.</h1>
 
 <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 @@ Release Notes</a>.</h1>
 
 <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 @@ Release Notes</a>.</h1>
    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>
 
-- 
cgit v1.1