The word `separate' only has one `e'.

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

4 files changed, 9 insertions, 9 deletions

diff --git a/docs/CommandLine.html b/docs/CommandLine.html
index 7c8c997a0f..7503015aa5 100644
--- a/docs/CommandLine.html
+++ b/docs/CommandLine.html
@@ -1109,7 +1109,7 @@ specifies that this option is used to capture "interpreter style" arguments.  Se
 
 <a name="cl::Prefix">The <b><tt>cl::Prefix</tt></b> modifier specifies that this
 option prefixes its value.  With 'Prefix' options, there is no equal sign that
-seperates the value from the option name specified.  This is useful for
+separates the value from the option name specified.  This is useful for
 processing odd arguments like '<tt>-lmalloc -L/usr/lib'</tt> in a linker tool.
 Here, the '<tt>l</tt>' and '<tt>L</tt>' options are normal string (list)
 options, that have the <a href="#cl::Prefix">cl::Prefix</a> modifier added to
@@ -1496,7 +1496,7 @@ line options </b></font></td></tr></table><ul>
 <address><a href="mailto:sabre@nondot.org">Chris Lattner</a></address>
 <!-- Created: Tue Jan 23 15:19:28 CST 2001 -->
 <!-- hhmts start -->
-Last modified: Sat Jun 21 16:45:29 CDT 2003
+Last modified: Mon Jul 14 12:12:15 CDT 2003
 <!-- hhmts end -->
 </font>
 </body></html>
diff --git a/docs/LangRef.html b/docs/LangRef.html
index 7b70c43831..79cb30eaeb 100644
--- a/docs/LangRef.html
+++ b/docs/LangRef.html
@@ -366,7 +366,7 @@ functions), for indirect function calls, and when defining a function.<p>
   &lt;returntype&gt; (&lt;parameter list&gt;)
 </pre>
 
-Where '<tt>&lt;parameter list&gt;</tt>' is a comma seperated list of type
+Where '<tt>&lt;parameter list&gt;</tt>' is a comma-separated list of type
 specifiers.  Optionally, the parameter list may include a type <tt>...</tt>,
 which indicates that the function takes a variable number of arguments.  Note
 that there currently is no way to define a function in LLVM that takes a
@@ -1811,7 +1811,7 @@ arbitrarily complex and require memory allocation, for example.<p>
 <address><a href="mailto:sabre@nondot.org">Chris Lattner</a></address>
 <!-- Created: Tue Jan 23 15:19:28 CST 2001 -->
 <!-- hhmts start -->
-Last modified: Wed Jun 18 16:29:55 CDT 2003
+Last modified: Mon Jul 14 12:12:22 CDT 2003
 <!-- hhmts end -->
 </font>
 </body></html>
diff --git a/docs/RegisterAllocatorInfo.txt b/docs/RegisterAllocatorInfo.txt
index 446ffa1efa..b20b635020 100644
--- a/docs/RegisterAllocatorInfo.txt
+++ b/docs/RegisterAllocatorInfo.txt
@@ -117,7 +117,7 @@ incoming/call arguments and return values.
 6.2. Create Interference graphs
 -------------------------------
 Once live ranges are constructed, we can build interference graphs for each
-register class. Though each register class must have a seperate interference
+register class. Though each register class must have a separate interference
 graph, building all interference graphs is performed in one pass. Also, the
 adjacency list for each live range is built in this phase. Consequently, each
 register class has an interference graph (which is a bit matrix) and each
@@ -139,7 +139,7 @@ coalesing is given in LiveRangeInfo::coalesceLRs().
 
 6.4. Color all live ranges in each RegClass using graph coloring algo
 ---------------------------------------------------------------------
-Each register class is colored seperately using the graph coloring algo. When
+Each register class is colored separately using the graph coloring algo. When
 assigning colors, preference is given to live ranges with suggested colors
 so that if such a live range receives a color (i.e., not spilled), then
 we try to assign the color suggested for that live range. When this phase
@@ -157,7 +157,7 @@ alogorithm, we have to make sure that it received the correct color (for
 instance the first incoming int argument must be colored to %i0 on Sparc). If
 it didn't receive the correct color, we have to insert instruction to to move
 the value to the required register. Also, this phase produces the caller 
-saving code. All adition code produced is kept seperately until the last
+saving code. All adition code produced is kept separately until the last
 phase (see 6.6)
 
 
diff --git a/docs/WritingAnLLVMPass.html b/docs/WritingAnLLVMPass.html
index 36dd24ef2e..c80fd848c5 100644
--- a/docs/WritingAnLLVMPass.html
+++ b/docs/WritingAnLLVMPass.html
@@ -1166,7 +1166,7 @@ fast enough: obviously we should allow for a multithreaded compiler.  Because of
 the semantics defined for passes above (specifically they cannot maintain state
 across invocations of their <tt>run*</tt> methods), a nice clean way to
 implement a multithreaded compiler would be for the <tt>PassManager</tt> class
-to create multiple instances of each pass object, and allow the seperate
+to create multiple instances of each pass object, and allow the separate
 instances to be hacking on different parts of the program at the same time.<p>
 
 This implementation would prevent each of the passes from having to implement
@@ -1223,6 +1223,6 @@ href="#Pass"><tt>Pass</tt></a>, only the other way around.<p>
 <address><a href="mailto:sabre@nondot.org">Chris Lattner</a></address>
 <!-- Created: Tue Aug  6 15:00:33 CDT 2002 -->
 <!-- hhmts start -->
-Last modified: Mon Oct 21 14:52:55 CDT 2002
+Last modified: Mon Jul 14 12:12:53 CDT 2003
 <!-- hhmts end -->
 </font></body></html>