diff --git a/docs/ReleaseNotes.html b/docs/ReleaseNotes.html
index f1538e0..1bc96bd 100644
--- a/docs/ReleaseNotes.html
+++ b/docs/ReleaseNotes.html
@@ -85,6 +85,9 @@
 LLVM release to do this.  One nice impact of this is that the LLVM regression
 test suite no longer depends on llvm-upgrade, which makes it run faster.</p>
 
+<p><tt>llvm2cpp</tt> tool has been folded into llc, use
+    <tt>llc -march=cpp</tt> instead of <tt>llvm2cpp</tt>.</p>
+
 <p>LLVM API Changes:</p>
 
 <ul>
@@ -249,8 +252,11 @@
 
 <li>LLVM now includes a simple 'Jump Threading' pass, which attempts to simplify
     conditional branches using information about predecessor blocks, simplifying
-    the control flow graph.  This pass is pretty basic at this point, but catches
-    some important cases and provides a foundation to build on.</li>
+    the control flow graph.  This pass is pretty basic at this point, but
+    catches some important cases and provides a foundation to build on.</li>
+    
+<li>Several corner case bugs which could lead to deleting volatile memory
+    accesses have been fixed.</li>
 </ul>
 
 </div>
@@ -275,7 +281,9 @@
     target-specific support. Use of APInt is also a step toward support for
     non-power-of-2 integer sizes.</li>
     
-<li>Several compile time speedups for code with large basic blocks.</li>
+<li>LLVM 2.3 includes several compile time speedups for code with large basic
+    blocks, particular in the instruction selection phase, register allocation,
+    scheduling, and tail merging/jump threading.</li>
 
 <li>Several improvements which make llc's <tt>--view-sunit-dags</tt>
     visualization of scheduling dependency graphs easier to understand.</li>
@@ -286,6 +294,16 @@
 <li><tt>memcpy</tt> lowering in the backend is more aggressive, particularly for
     <tt>memcpy</tt> calls introduced by the code generator when handling
     pass-by-value structure argument copies.</li>
+    
+<li>Inline assembly with multiple register results now returns those results
+    directly in the appropriate registers, rather than going through memory.
+    Inline assembly that uses constraints like "ir" with immediates now use the
+    'i' form when possible instead of always loading the value in a register.
+    This saves an instruction and reduces register use.</li>
+
+<li>Added support for PIC/GOT style tail calls on x86/32 and initial support
+    for tail calls on PowerPC 32 (it may also work on ppc64 but not
+    thoroughly tested).</li>
 </ul>
 
 </div>
@@ -336,6 +354,9 @@
 
 <li>The register allocator can now rematerialize PIC-base computations.</li>
 
+<li>The "t" and "f" inline assembly constraints for the X87 floating point stack
+    now work.  However, the "u" constraint is still not fully supported.</li>
+
 </ul>
   
 </div>
@@ -351,8 +372,6 @@
 
 <ul>
 <li>The LLVM C backend now supports vector code.</li>
-    
-
 </ul>
   
 </div>
@@ -370,8 +389,9 @@
 
 <ul>
 <li>LLVM now builds with GCC 4.3.</li>
-<li><tt>llvm2cpp</tt> tool has been folded into llc, use
-    <tt>llc -march=cpp</tt></li>
+<li>Bugpoint now supports running custom scripts (with the <tt>-run-custom</tt>
+    option) to determine how to execute the command and whether it is making
+    forward process.</li>
 </ul>
   
 </div>
@@ -456,8 +476,8 @@
     all <a href="http://llvm.org/PR879">inline assembly that uses the X86
     floating point stack</a>.  It supports the 'f' and 't' constraints, but not
     'u'.</li>
-  <li>The X86 backend generates inefficient floating point code when configured to
-    generate code for systems that don't have SSE2.</li>
+  <li>The X86 backend generates inefficient floating point code when configured
+    to generate code for systems that don't have SSE2.</li>
   <li>Win64 code generation wasn't widely tested. Everything should work, but we
     expect small issues to happen. Also, llvm-gcc cannot build mingw64 runtime
     currently due
@@ -494,7 +514,8 @@
 results (<a href="http://llvm.org/PR1388">PR1388</a>).</li>
 <li>Compilation for ARM Linux OABI (old ABI) is supported, but not fully tested.
 </li>
-<li>There is a bug in QEMU-ARM (&lt;= 0.9.0) which causes it to incorrectly execute
+<li>There is a bug in QEMU-ARM (&lt;= 0.9.0) which causes it to incorrectly
+ execute
 programs compiled with LLVM.  Please use more recent versions of QEMU.</li>
 </ul>
 
@@ -651,11 +672,12 @@
 or finish at a non-byte offset</a> in a record.  Workaround: do not pack records
 or use representation clauses that result in a field of a non-discrete type
 starting or finishing in the middle of a byte.</li>
-<li>The <tt>lli</tt> interpreter <a href="http://llvm.org/PR2009">considers 'main'
-as generated by the Ada binder to be invalid</a>.
-Workaround: hand edit the file to use pointers for <tt>argv</tt> and <tt>envp</tt> rather than
-integers.</li>
-<li>The <tt>-fstack-check</tt> option <a href="http://llvm.org/PR2008">is ignored</a>.</li>
+<li>The <tt>lli</tt> interpreter <a href="http://llvm.org/PR2009">considers
+'main' as generated by the Ada binder to be invalid</a>.
+Workaround: hand edit the file to use pointers for <tt>argv</tt> and
+<tt>envp</tt> rather than integers.</li>
+<li>The <tt>-fstack-check</tt> option <a href="http://llvm.org/PR2008">is
+ignored</a>.</li>
 </ul>
 </div>