From: Wesley Peck <peckw@wesleypeck.com>
Date: Thu, 22 Apr 2010 13:28:34 +0000 (+0000)
Subject: Reworking the wording of the "target data string" paragraph in the "Optimizer Improvm... 
X-Git-Url: http://plrg.eecs.uci.edu/git/?a=commitdiff_plain;h=68d1fe9700346f06bb7d05bdd0741f272a32e4fe;p=oota-llvm.git

Reworking the wording of the "target data string" paragraph in the "Optimizer Improvments" section of the release notes.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102059 91177308-0d34-0410-b5e6-96231b3b80d8
---

diff --git a/docs/ReleaseNotes.html b/docs/ReleaseNotes.html
index c4b7185c896..664c1970240 100644
--- a/docs/ReleaseNotes.html
+++ b/docs/ReleaseNotes.html
@@ -544,11 +544,10 @@ href="http://blog.llvm.org/2009/12/introduction-to-load-elimination-in-gvn.html"
  Advanced Topics in Redundant Load Elimination with a Focus on PHI Translation
  Blog Post</a> for more details.</li>
 <li>The module <a href="LangRef.html#datalayout">target data string</a> now
-    includes a notion of what the 'native' integer data types a for the target,
-    which allows various optimizations to use.  This helps mid-level
-    optimizations avoid promoting complex sequences of operations to data types
-    that are not natively supported (e.g. converting i32 operations to i64 on
-    a 32-bit chip).</li>
+    includes a notion of 'native' integer data types for the target. This
+    helps mid-level optimizations avoid promoting complex sequences of
+    operations to data types that are not natively supported (e.g. converting
+    i32 operations to i64 on 32-bit chips).</li>
 <li>The mid-level optimizer is now conservative when operating on a module with
     no target data.  Previously, it would default to SparcV9 settings, which is
     not what most people expected.</li>