add scaffolding for splitting of vectors.

[oota-llvm.git] / docs / ReleaseNotes.html

diff --git a/docs/ReleaseNotes.html b/docs/ReleaseNotes.html
index aa11404d3c619996c847345ac82d09f424ac2f7c..d2c61176fa67216220d37a5ee1b6f4cebb874bd4 100644 (file)
--- a/docs/ReleaseNotes.html
+++ b/docs/ReleaseNotes.html
@@ -149,7 +149,7 @@ optimizer, speeding it up and making it more aggressive.  For example:</p>
 <li>Evan contributed a new target independent if-converter.  While it is 
     target independent, so far only the ARM backend uses it.</li>
 
-<li>Evan rewrite the way the register allocator handles rematerialization,
+<li>Evan rewrote the way the register allocator handles rematerialization,
     allowing it to be much more effective on two-address targets like X86,
     and taught it to fold loads away when possible (also a big win on X86).</li>
 
@@ -226,7 +226,7 @@ optimizer, speeding it up and making it more aggressive.  For example:</p>
 "restrict" pointer arguments to functions.</li>
 
 <li>Duncan contributed support for trampolines (taking the address of a nested
-    function).  Currently this is only supported on the X86 target.</li>
+    function).  Currently this is only supported on the X86-32 target.</li>
 
 <li>Lauro Ramos Venancio contributed support to encode alignment info in 
     load and store instructions, the foundation for other alignment-related
@@ -529,7 +529,7 @@ bits.</p></li>
 
       As in Algol and Pascal, lexical scoping of functions.
       Nested functions are supported, but llvm-gcc does not support
-      taking the address of a nested function (except on the X86 target)
+      taking the address of a nested function (except on the X86-32 target)
       or non-local gotos.</li>
 
   <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#Function%20Attributes">Function Attributes</a>:
@@ -537,15 +537,16 @@ bits.</p></li>
       Declaring that functions have no side effects or that they can never
       return.<br>
 
-      <b>Supported:</b> <tt>alias</tt>, <tt>always_inline</tt>, <tt>cdecl</tt>,
-      <tt>constructor</tt>, <tt>destructor</tt>,
+      <b>Supported:</b> <tt>alias</tt>, <tt>always_inline</tt>, <tt>cdecl</tt>, 
+      <tt>const</tt>, <tt>constructor</tt>, <tt>destructor</tt>, 
       <tt>deprecated</tt>, <tt>fastcall</tt>, <tt>format</tt>, 
-      <tt>format_arg</tt>, <tt>non_null</tt>, <tt>noinline</tt>, <tt>noreturn</tt>, <tt>regparm</tt>
+      <tt>format_arg</tt>, <tt>non_null</tt>, <tt>noinline</tt>, 
+      <tt>noreturn</tt>, <tt>pure</tt>, <tt>regparm</tt>
       <tt>section</tt>, <tt>stdcall</tt>, <tt>unused</tt>, <tt>used</tt>, 
       <tt>visibility</tt>, <tt>warn_unused_result</tt>, <tt>weak</tt><br>
 
-      <b>Ignored:</b> <tt>pure</tt>, <tt>const</tt>, <tt>nothrow</tt>,
-      <tt>malloc</tt>, <tt>no_instrument_function</tt></li>
+      <b>Ignored:</b> <tt>nothrow</tt>, <tt>malloc</tt>,
+      <tt>no_instrument_function</tt></li>
   </ol>
 </li>
 
@@ -622,7 +623,7 @@ tested and works for a number of non-trivial programs, including LLVM
 itself, Qt, Mozilla, etc.</p>
 
 <ul>
-<li>Exception handling only works well on the linux/x86-32 target.
+<li>Exception handling only works well on the linux/X86-32 target.
 In some cases, illegally throwing an exception does not result
 in a call to terminate.</li>