Documentation: Perform automated correction of common typos.

llvm-svn: 83849

docs/BitCodeFormat.html

@@ -254,7 +254,7 @@ Blocks in a bitstream denote nested regions of the stream, and are identified by
 a content-specific id number (for example, LLVM IR uses an ID of 12 to represent
 function bodies).  Block IDs 0-7 are reserved for <a href="#stdblocks">standard blocks</a>
 whose meaning is defined by Bitcode; block IDs 8 and greater are
-application specific. Nested blocks capture the hierachical structure of the data
+application specific. Nested blocks capture the hierarchical structure of the data
 encoded in it, and various properties are associated with blocks as the file is
 parsed.  Block definitions allow the reader to efficiently skip blocks
 in constant time if the reader wants a summary of blocks, or if it wants to

docs/CodingStandards.html

@@ -303,7 +303,7 @@ for debate.</p>
 <div class="doc_text">
 
 <p>In all cases, prefer spaces to tabs in source files.  People have different
-prefered indentation levels, and different styles of indentation that they
+preferred indentation levels, and different styles of indentation that they
 like... this is fine.  What isn't is that different editors/viewers expand tabs
 out to different tab stops.  This can cause your code to look completely
 unreadable, and it is not worth dealing with.</p>
@@ -491,7 +491,7 @@ most cases, you simply don't need the definition of a class... and not
 <b>must</b> include all of the header files that you are using -- you can 
 include them either directly
 or indirectly (through another header file).  To make sure that you don't
-accidently forget to include a header file in your module header, make sure to
+accidentally forget to include a header file in your module header, make sure to
 include your module header <b>first</b> in the implementation file (as mentioned
 above).  This way there won't be any hidden dependencies that you'll find out
 about later...</p>
@@ -790,7 +790,7 @@ locality.</p>
 <div class="doc_text">
 
 <p>Use the "<tt>assert</tt>" function to its fullest.  Check all of your
-preconditions and assumptions, you never know when a bug (not neccesarily even
+preconditions and assumptions, you never know when a bug (not necessarily even
 yours) might be caught early by an assertion, which reduces debugging time
 dramatically.  The "<tt>&lt;cassert&gt;</tt>" header file is probably already
 included by the header files you are using, so it doesn't cost anything to use

docs/CommandLine.html

@@ -1022,7 +1022,7 @@ files that use them.  This is called the internal storage model.</p>
 code from the storage of the value parsed.  For example, lets say that we have a
 '<tt>-debug</tt>' option that we would like to use to enable debug information
 across the entire body of our program.  In this case, the boolean value
-controlling the debug code should be globally accessable (in a header file, for
+controlling the debug code should be globally accessible (in a header file, for
 example) yet the command line option processing code should not be exposed to
 all of these clients (requiring lots of .cpp files to #include
 <tt>CommandLine.h</tt>).</p>
@@ -1107,7 +1107,7 @@ a command line option.  Look <a href="#value_desc_example">here</a> for an
 example.</li>
 
 <li><a name="cl::init">The <b><tt>cl::init</tt></b></a> attribute specifies an
-inital value for a <a href="#cl::opt">scalar</a> option.  If this attribute is
+initial value for a <a href="#cl::opt">scalar</a> option.  If this attribute is
 not specified then the command line option value defaults to the value created
 by the default constructor for the type. <b>Warning</b>: If you specify both
 <b><tt>cl::init</tt></b> and <b><tt>cl::location</tt></b> for an option,
@@ -1178,7 +1178,7 @@ href="#cl::list">cl::list</a></tt>.  These modifiers give you the ability to
 tweak how options are parsed and how <tt>--help</tt> output is generated to fit
 your application well.</p>
 
-<p>These options fall into five main catagories:</p>
+<p>These options fall into five main categories:</p>
 
 <ol>
 <li><a href="#hiding">Hiding an option from <tt>--help</tt> output</a></li>
@@ -1190,9 +1190,9 @@ your application well.</p>
 <li><a href="#misc">Miscellaneous option modifiers</a></li>
 </ol>
 
-<p>It is not possible to specify two options from the same catagory (you'll get
+<p>It is not possible to specify two options from the same category (you'll get
 a runtime error) to a single option, except for options in the miscellaneous
-catagory.  The CommandLine library specifies defaults for all of these settings
+category.  The CommandLine library specifies defaults for all of these settings
 that are the most useful in practice and the most common, which mean that you
 usually shouldn't have to worry about these.</p>
 
@@ -1536,7 +1536,7 @@ not be available, it can't just look in <tt>argv[0]</tt>), the name of the
 environment variable to examine, the optional
 <a href="#description">additional extra text</a> to emit when the
 <tt>--help</tt> option is invoked, and the boolean
-switch that controls whether <a href="#response">reponse files</a>
+switch that controls whether <a href="#response">response files</a>
 should be read.</p>
 
 <p><tt>cl::ParseEnvironmentOptions</tt> will break the environment

docs/CompilerDriver.html

@@ -307,13 +307,13 @@ separate option groups syntactically.</p>
 <tt class="docutils literal"><span class="pre">-std=c99</span></tt>. It is also allowed to use spaces instead of the equality
 sign: <tt class="docutils literal"><span class="pre">-std</span> <span class="pre">c99</span></tt>. At most one occurrence is allowed.</li>
 <li><tt class="docutils literal"><span class="pre">parameter_list_option</span></tt> - same as the above, but more than one option
-occurence is allowed.</li>
+occurrence is allowed.</li>
 <li><tt class="docutils literal"><span class="pre">prefix_option</span></tt> - same as the parameter_option, but the option name and
 argument do not have to be separated. Example: <tt class="docutils literal"><span class="pre">-ofile</span></tt>. This can be also
 specified as <tt class="docutils literal"><span class="pre">-o</span> <span class="pre">file</span></tt>; however, <tt class="docutils literal"><span class="pre">-o=file</span></tt> will be parsed incorrectly
 (<tt class="docutils literal"><span class="pre">=file</span></tt> will be interpreted as option value). At most one occurrence is
 allowed.</li>
-<li><tt class="docutils literal"><span class="pre">prefix_list_option</span></tt> - same as the above, but more than one occurence of
+<li><tt class="docutils literal"><span class="pre">prefix_list_option</span></tt> - same as the above, but more than one occurrence of
 the option is allowed; example: <tt class="docutils literal"><span class="pre">-lm</span> <span class="pre">-lpthread</span></tt>.</li>
 <li><tt class="docutils literal"><span class="pre">alias_option</span></tt> - a special option type for creating aliases. Unlike other
 option types, aliases are not allowed to have any properties besides the
@@ -682,7 +682,7 @@ the <tt class="docutils literal"><span class="pre">Base</span></tt> plugin behav
 <a href="mailto:foldr@codedgers.com">Mikhail Glushenkov</a><br />
 <a href="http://llvm.org">LLVM Compiler Infrastructure</a><br />
 
-Last modified: $Date: 2008-12-11 11:34:48 -0600 (Thu, 11 Dec 2008) $
+Last modified: $Date$
 </address></div>
 </div>
 </div>

docs/FAQ.html

@@ -685,7 +685,7 @@ Stop.
 <p>Also, there are a number of other limitations of the C backend that cause it
    to produce code that does not fully conform to the C++ ABI on most
    platforms. Some of the C++ programs in LLVM's test suite are known to fail
-   when compiled with the C back end because of ABI incompatiblities with
+   when compiled with the C back end because of ABI incompatibilities with
    standard C++ libraries.</p>
 </div>
 
@@ -700,7 +700,7 @@ Stop.
    portable is by using the preprocessor to include platform-specific code. In
    practice, information about other platforms is lost after preprocessing, so
    the result is inherently dependent on the platform that the preprocessing was
-   targetting.</p>
+   targeting.</p>
 
 <p>Another example is <tt>sizeof</tt>. It's common for <tt>sizeof(long)</tt> to
    vary between platforms. In most C front-ends, <tt>sizeof</tt> is expanded to

docs/GetElementPtr.html

@@ -40,7 +40,7 @@
 <div class="doc_text"> 
   <p>This document seeks to dispel the mystery and confusion surrounding LLVM's
   GetElementPtr (GEP) instruction. Questions about the wiley GEP instruction are
-  probably the most frequently occuring questions once a developer gets down to
+  probably the most frequently occurring questions once a developer gets down to
   coding with LLVM. Here we lay out the sources of confusion and show that the
   GEP instruction is really quite simple.
   </p>

docs/HowToReleaseLLVM.html

@@ -40,7 +40,7 @@
 <div class="doc_text">
   <p>LLVM is released on a time based schedule (currently every 6 months). We
   do not have dot releases because of the nature of LLVM incremental 
-  developement philosophy. The release schedule is roughly as follows:
+  development philosophy. The release schedule is roughly as follows:
   </p>
 <ol>
 <li>Set code freeze and branch creation date for 6 months after last code freeze 
@@ -499,7 +499,7 @@ svn copy https://llvm.org/svn/llvm-project/test-suite/branches/release_XX \
   release documentation.</li>
   <li> Finally, update the main page (<tt>index.html</tt> and sidebar) to
   point to the new release and release announcement. Make sure this all gets
-  commited back into Subversion.</li>
+  committed back into Subversion.</li>
   </ol>
 </div>
 

docs/HowToSubmitABug.html

@@ -60,7 +60,7 @@ more easily.</p>
 <p>Once you have a reduced test-case, go to <a
 href="http://llvm.org/bugs/enter_bug.cgi">the LLVM Bug Tracking
 System</a> and fill out the form with the necessary details (note that you don't
-need to pick a catagory, just use the "new-bugs" catagory if you're not sure).
+need to pick a category, just use the "new-bugs" category if you're not sure).
 The bug description should contain the following
 information:</p>
 

docs/LangRef.html

@@ -2019,7 +2019,7 @@ Classifications</a> </div>
 <div class="doc_text">
 
 <p>The string '<tt>undef</tt>' can be used anywhere a constant is expected, and
-   indicates that the user of the value may recieve an unspecified bit-pattern.
+   indicates that the user of the value may receive an unspecified bit-pattern.
    Undefined values may be of any type (other than label or void) and be used
    anywhere a constant is permitted.</p>
 
@@ -2118,7 +2118,7 @@ number of reasons, but the short answer is that an undef "variable" can
 arbitrarily change its value over its "live range".  This is true because the
 "variable" doesn't actually <em>have a live range</em>.  Instead, the value is
 logically read from arbitrary registers that happen to be around when needed,
-so the value is not neccesarily consistent over time.  In fact, %A and %C need
+so the value is not necessarily consistent over time.  In fact, %A and %C need
 to have the same semantics or the core LLVM "replace all uses with" concept
 would not hold.</p>
 
@@ -2300,7 +2300,7 @@ has undefined behavior.</p>
    the two digit hex code.  For example: "<tt>!"test\00"</tt>".</p>
 
 <p>Metadata nodes are represented with notation similar to structure constants
-   (a comma separated list of elements, surrounded by braces and preceeded by an
+   (a comma separated list of elements, surrounded by braces and preceded by an
    exclamation point).  For example: "<tt>!{ metadata !"test\00", i32
    10}</tt>".</p>
 
@@ -2619,8 +2619,8 @@ IfUnequal:
 <p>The <tt>switch</tt> instruction specifies a table of values and
    destinations. When the '<tt>switch</tt>' instruction is executed, this table
    is searched for the given value.  If the value is found, control flow is
-   transfered to the corresponding destination; otherwise, control flow is
+   transferred to the corresponding destination; otherwise, control flow is
-   transfered to the default destination.</p>
+   transferred to the default destination.</p>
 
 <h5>Implementation:</h5>
 <p>Depending on properties of the target machine and the particular

docs/LinkTimeOptimization.html

@@ -166,7 +166,7 @@ $ llvm-gcc a.o main.o -o main # <-- standard link command without any modific
     provided by the linker on various platform are not unique. This means, 
     this new tool needs to support all such features and platforms in one 
     super tool or a separate tool per platform is required. This increases 
-    maintance cost for link time optimizer significantly, which is not 
+    maintenance cost for link time optimizer significantly, which is not 
     necessary. This approach also requires staying synchronized with linker 
     developements on various platforms, which is not the main focus of the link 
     time optimizer. Finally, this approach increases end user's build time due 
@@ -189,7 +189,7 @@ $ llvm-gcc a.o main.o -o main # <-- standard link command without any modific
   user-supplied information, such as a list of exported symbols. LLVM 
   optimizer collects control flow information, data flow information and knows 
   much more about program structure from the optimizer's point of view. 
-  Our goal is to take advantage of tight intergration between the linker and 
+  Our goal is to take advantage of tight integration between the linker and 
   the optimizer by sharing this information during various linking phases.
 </p>
 </div>

docs/MakefileGuide.html

@@ -261,7 +261,7 @@
 <!-- ======================================================================= -->
 <div class="doc_subsubsection"><a name="BCModules">Bitcode Modules</a></div>
 <div class="doc_text">
-  <p>In some situations, it is desireable to build a single bitcode module from
+  <p>In some situations, it is desirable to build a single bitcode module from
   a variety of sources, instead of an archive, shared library, or bitcode 
   library. Bitcode modules can be specified in addition to any of the other
   types of libraries by defining the <a href="#MODULE_NAME">MODULE_NAME</a>

docs/Passes.html

@@ -1544,7 +1544,7 @@ if (X &lt; 3) {</pre>
   <p>
   This file demotes all registers to memory references.  It is intented to be
   the inverse of <a href="#mem2reg"><tt>-mem2reg</tt></a>.  By converting to
-  <tt>load</tt> instructions, the only values live accross basic blocks are
+  <tt>load</tt> instructions, the only values live across basic blocks are
   <tt>alloca</tt> instructions and <tt>load</tt> instructions before
   <tt>phi</tt> nodes. It is intended that this should make CFG hacking much 
   easier. To make later hacking easier, the entry block is split into two, such

docs/ProgrammersManual.html

@@ -650,7 +650,7 @@ even if the source lives in multiple files.</p>
 <p>The <tt>DEBUG_WITH_TYPE</tt> macro is also available for situations where you
 would like to set <tt>DEBUG_TYPE</tt>, but only for one specific <tt>DEBUG</tt>
 statement. It takes an additional first parameter, which is the type to use. For
-example, the preceeding example could be written as:</p>
+example, the preceding example could be written as:</p>
 
 
 <div class="doc_code">
@@ -2983,7 +2983,7 @@ the <tt>lib/VMCore</tt> directory.</p>
   <dt><tt>VectorType</tt></dt>
   <dd>Subclass of SequentialType for vector types. A 
   vector type is similar to an ArrayType but is distinguished because it is 
-  a first class type wherease ArrayType is not. Vector types are used for 
+  a first class type whereas ArrayType is not. Vector types are used for 
   vector operations and are usually small vectors of of an integer or floating 
   point type.</dd>
   <dt><tt>StructType</tt></dt>
@@ -3552,7 +3552,7 @@ of a list of <a href="#BasicBlock"><tt>BasicBlock</tt></a>s, a list of formal
 <p>The list of <a href="#BasicBlock"><tt>BasicBlock</tt></a>s is the most
 commonly used part of <tt>Function</tt> objects.  The list imposes an implicit
 ordering of the blocks in the function, which indicate how the code will be
-layed out by the backend.  Additionally, the first <a
+laid out by the backend.  Additionally, the first <a
 href="#BasicBlock"><tt>BasicBlock</tt></a> is the implicit entry node for the
 <tt>Function</tt>.  It is not legal in LLVM to explicitly branch to this initial
 block.  There are no implicit exit nodes, and in fact there may be multiple exit
@@ -3682,7 +3682,7 @@ Superclasses: <a href="#GlobalValue"><tt>GlobalValue</tt></a>,
 <a href="#User"><tt>User</tt></a>,
 <a href="#Value"><tt>Value</tt></a></p>
 
-<p>Global variables are represented with the (suprise suprise)
+<p>Global variables are represented with the (surprise surprise)
 <tt>GlobalVariable</tt> class. Like functions, <tt>GlobalVariable</tt>s are also
 subclasses of <a href="#GlobalValue"><tt>GlobalValue</tt></a>, and as such are
 always referenced by their address (global values must live in memory, so their
@@ -3732,7 +3732,7 @@ never change at runtime).</p>
 
   <li><tt><a href="#Constant">Constant</a> *getInitializer()</tt>
 
-    <p>Returns the intial value for a <tt>GlobalVariable</tt>.  It is not legal
+    <p>Returns the initial value for a <tt>GlobalVariable</tt>.  It is not legal
     to call this method if there is no initializer.</p></li>
 </ul>
 

docs/SourceLevelDebugging.html

@@ -288,7 +288,7 @@ height="369">
    way.  Also, all debugging information objects start with a tag to indicate
    what type of object it is.  The source-language is allowed to define its own
    objects, by using unreserved tag numbers.  We recommend using with tags in
-   the range 0x1000 thru 0x2000 (there is a defined enum DW_TAG_user_base =
+   the range 0x1000 through 0x2000 (there is a defined enum DW_TAG_user_base =
    0x1000.)</p>
 
 <p>The fields of debug descriptors used internally by LLVM 

docs/WritingAnLLVMPass.html

@@ -453,7 +453,7 @@ available, from the most general to the most specific.</p>
 <p>When choosing a superclass for your Pass, you should choose the <b>most
 specific</b> class possible, while still being able to meet the requirements
 listed.  This gives the LLVM Pass Infrastructure information necessary to
-optimize how passes are run, so that the resultant compiler isn't unneccesarily
+optimize how passes are run, so that the resultant compiler isn't unnecessarily
 slow.</p>
 
 </div>
@@ -492,7 +492,7 @@ invalidated, and are never "run".</p>
 href="http://llvm.org/doxygen/classllvm_1_1ModulePass.html">ModulePass</a></tt>"
 class is the most general of all superclasses that you can use.  Deriving from
 <tt>ModulePass</tt> indicates that your pass uses the entire program as a unit,
-refering to function bodies in no predictable order, or adding and removing
+referring to function bodies in no predictable order, or adding and removing
 functions.  Because nothing is known about the behavior of <tt>ModulePass</tt>
 subclasses, no optimization can be done for their execution.</p>
 

docs/tutorial/LangImpl3.html

@@ -183,7 +183,7 @@ Value *VariableExprAST::Codegen() {
 </div>
 
 <p>References to variables are also quite simple using LLVM.  In the simple version
-of Kaleidoscope, we assume that the variable has already been emited somewhere
+of Kaleidoscope, we assume that the variable has already been emitted somewhere
 and its value is available.  In practice, the only values that can be in the
 <tt>NamedValues</tt> map are function arguments.  This
 code simply checks to see that the specified name is in the map (if not, an 
@@ -362,7 +362,7 @@ definition of this function.</p>
 first, we want to allow 'extern'ing a function more than once, as long as the
 prototypes for the externs match (since all arguments have the same type, we
 just have to check that the number of arguments match).  Second, we want to
-allow 'extern'ing a function and then definining a body for it.  This is useful
+allow 'extern'ing a function and then defining a body for it.  This is useful
 when defining mutually recursive functions.</p>
 
 <p>In order to implement this, the code above first checks to see if there is

docs/tutorial/LangImpl4.html

@@ -209,7 +209,7 @@ requires a pointer to the <tt>Module</tt> (through the <tt>ModuleProvider</tt>)
 to construct itself.  Once it is set up, we use a series of "add" calls to add
 a bunch of LLVM passes.  The first pass is basically boilerplate, it adds a pass
 so that later optimizations know how the data structures in the program are
-layed out.  The "<tt>TheExecutionEngine</tt>" variable is related to the JIT,
+laid out.  The "<tt>TheExecutionEngine</tt>" variable is related to the JIT,
 which we will get to in the next section.</p>
 
 <p>In this case, we choose to add 4 optimization passes.  The passes we chose

docs/tutorial/OCamlLangImpl3.html

@@ -159,7 +159,7 @@ uses "the foo::get(..)" idiom instead of "new foo(..)" or "foo::Create(..)".</p>
 </div>
 
 <p>References to variables are also quite simple using LLVM.  In the simple
-version of Kaleidoscope, we assume that the variable has already been emited
+version of Kaleidoscope, we assume that the variable has already been emitted
 somewhere and its value is available.  In practice, the only values that can be
 in the <tt>Codegen.named_values</tt> map are function arguments.  This code
 simply checks to see that the specified name is in the map (if not, an unknown
@@ -323,7 +323,7 @@ code above.</p>
 first, we want to allow 'extern'ing a function more than once, as long as the
 prototypes for the externs match (since all arguments have the same type, we
 just have to check that the number of arguments match).  Second, we want to
-allow 'extern'ing a function and then definining a body for it.  This is useful
+allow 'extern'ing a function and then defining a body for it.  This is useful
 when defining mutually recursive functions.</p>
 
 <div class="doc_code">

docs/tutorial/OCamlLangImpl4.html

@@ -224,7 +224,7 @@ requires a pointer to the <tt>the_module</tt> (through the
 <tt>the_module_provider</tt>) to construct itself.  Once it is set up, we use a
 series of "add" calls to add a bunch of LLVM passes.  The first pass is
 basically boilerplate, it adds a pass so that later optimizations know how the
-data structures in the program are layed out.  The
+data structures in the program are laid out.  The
 "<tt>the_execution_engine</tt>" variable is related to the JIT, which we will
 get to in the next section.</p>