s/teh/the and other grammos

[eax]

Summary

all those words make teh duplicate duplicate words and other mistakes hard to find

[eax]

include a variety of other grammos as well

[mkuper]

Thanks! :)
A couple of minor comments.

docs/ProgrammersManual.rst

943 ↗

(On Diff #22417)

I think this should have been "it is".

docs/tutorial/LangImpl7.rst

635 ↗

(On Diff #22417)

As long as we're fixing grammar here, shouldn't it be "other extension"?

[eax]

Per mkuper

[mkuper]

LGTM

[eax]

@davide ping?

[mkuper]

Do you need me to commit this for you?

llvm/trunk/docs/Bugpoint.rst

.. code-block:: c++
   DEBUG(dbgs() << "I: "; I->dump());
 
 could be added to ``visitXOR`` to limit ``visitXor`` to being applied only to
 calls 212 and 217. This is from an actual test case and raises an important
 point---a simple binary search may not be sufficient, as transformations that
 interact may require isolating more than one call.  In TargetLowering, use
 ``return SDNode();`` instead of ``return false;``.
 
-Now that that the number of transformations is down to a manageable number, try
+Now that the number of transformations is down to a manageable number, try
 examining the output to see if you can figure out which transformations are
 being done.  If that can be figured out, then do the usual debugging.  If which
 code corresponds to the transformation being performed isn't obvious, set a
 breakpoint after the call count based disabling and step through the code.
 Alternatively, you can use "``printf``" style debugging to report waypoints.

llvm/trunk/docs/LangRef.rst

 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 ``noalias`` and ``alias.scope`` metadata provide the ability to specify generic
 noalias memory-access sets. This means that some collection of memory access
 instructions (loads, stores, memory-accessing calls, etc.) that carry
 ``noalias`` metadata can specifically be specified not to alias with some other
 collection of memory access instructions that carry ``alias.scope`` metadata.
 Each type of metadata specifies a list of scopes where each scope has an id and
-a domain. When evaluating an aliasing query, if for some some domain, the set
+a domain. When evaluating an aliasing query, if for some domain, the set
 of scopes with that domain in one instruction's ``alias.scope`` list is a
 subset of (or equal to) the set of scopes for that domain in another
 instruction's ``noalias`` list, then the two memory accesses are assumed not to
 alias.
 
 The metadata identifying each domain is itself a list containing one or two
 entries. The first entry is the name of the domain. Note that if the name is a
 string then it can be combined accross functions and translation units. A

 
 The '``ptrtoint``' instruction converts the pointer or a vector of
 pointers ``value`` to the integer (or vector of integers) type ``ty2``.
 
 Arguments:
 """"""""""
 
 The '``ptrtoint``' instruction takes a ``value`` to cast, which must be
-a a value of type :ref:`pointer <t_pointer>` or a vector of pointers, and a
+a value of type :ref:`pointer <t_pointer>` or a vector of pointers, and a
 type to cast it to ``ty2``, which must be an :ref:`integer <t_integer>` or
 a vector of integers type.
 
 Semantics:
 """"""""""
 
 The '``ptrtoint``' instruction converts ``value`` to integer type
 ``ty2`` by interpreting the pointer value as an integer and either

llvm/trunk/docs/ProgrammersManual.rst

 
 String-like containers
 ----------------------
 
 There are a variety of ways to pass around and use strings in C and C++, and
 LLVM adds a few new options to choose from.  Pick the first option on this list
 that will do what you need, they are ordered according to their relative cost.
 
-Note that is is generally preferred to *not* pass strings around as ``const
+Note that it is generally preferred to *not* pass strings around as ``const
 char*``'s.  These have a number of problems, including the fact that they
 cannot represent embedded nul ("\0") characters, and do not have a length
 available efficiently.  The general replacement for '``const char*``' is
 StringRef.
 
 For more information on choosing string containers for APIs, please see
 :ref:`Passing Strings <string_apis>`.
 

 
 ``PointerType``
   Subclass of SequentialType for pointer types.
 
 ``VectorType``
   Subclass of SequentialType for vector types.  A vector type is similar to an
   ArrayType but is distinguished because it is 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.
+  small vectors of an integer or floating point type.
 
 ``StructType``
   Subclass of DerivedTypes for struct types.
 
 .. _FunctionType:
 
 ``FunctionType``
   Subclass of DerivedTypes for function types.

llvm/trunk/docs/Vectorizers.rst

.. code-block:: c++
   }
 
 The Loop Vectorizer uses a cost model to decide when it is profitable to unroll loops.
 The decision to unroll the loop depends on the register pressure and the generated code size. 
 
 Performance
 -----------
 
-This section shows the the execution time of Clang on a simple benchmark:
+This section shows the execution time of Clang on a simple benchmark:
 `gcc-loops <http://llvm.org/viewvc/llvm-project/test-suite/trunk/SingleSource/UnitTests/Vectorizer/>`_.
 This benchmarks is a collection of loops from the GCC autovectorization
 `page <http://gcc.gnu.org/projects/tree-ssa/vectorization.html>`_ by Dorit Nuzman.
 
 The chart below compares GCC-4.7, ICC-13, and Clang-SVN with and without loop vectorization at -O3, tuned for "corei7-avx", running on a Sandybridge iMac.
 The Y-axis shows the time in msec. Lower is better. The last column shows the geomean of all the kernels.
 
 .. image:: gcc-loops.png

llvm/trunk/docs/YamlIO.rst

.. code-block:: c++
     template <>
     struct MappingTraits<Info> {
       static void mapping(IO &io, Info &info) {
         io.mapRequired("cpu",       info.cpu);
         io.mapOptional("flags",     info.flags, 0);
       }
     };
 
-When reading YAML, if the string found does not match any of the the strings
+When reading YAML, if the string found does not match any of the strings
 specified by enumCase() methods, an error is automatically generated.
 When writing YAML, if the value being written does not match any of the values
 specified by the enumCase() methods, a runtime assertion is triggered.
   
 
 BitValue
 --------
 Another common data structure in C++ is a field where each bit has a unique
struct SequenceTraits<MyList> {
     static size_t size(IO &io, MyList &list) { ... }
     static MyListEl &element(IO &io, MyList &list, size_t index) { ... }
     
     // The existence of this member causes YAML I/O to use a flow sequence
     static const bool flow = true;
   };
 
 With the above, if you used MyList as the data type in your native data 
-structures, then then when converted to YAML, a flow sequence of integers 
+structures, then when converted to YAML, a flow sequence of integers 
 will be used (e.g. [ 10, -3, 4 ]).
 
 
 Utility Macros
 --------------
 Since a common source of sequences is std::vector<>, YAML I/O provides macros:
 LLVM_YAML_IS_SEQUENCE_VECTOR() and LLVM_YAML_IS_FLOW_SEQUENCE_VECTOR() which
 can be used to easily specify SequenceTraits<> on a std::vector type.  YAML 

llvm/trunk/docs/tutorial/LangImpl5.rst

 #. Code that involves user variables: ``x = 1; x = x + 1;``
 #. Values that are implicit in the structure of your AST, such as the
    Phi node in this case.
 
 In `Chapter 7 <LangImpl7.html>`_ of this tutorial ("mutable variables"),
 we'll talk about #1 in depth. For now, just believe me that you don't
 need SSA construction to handle this case. For #2, you have the choice
 of using the techniques that we will describe for #1, or you can insert
-Phi nodes directly, if convenient. In this case, it is really really
+Phi nodes directly, if convenient. In this case, it is really
 easy to generate the Phi node, so we choose to do it directly.
 
 Okay, enough of the motivation and overview, lets generate code!
 
 Code Generation for If/Then/Else
 --------------------------------
 
 In order to generate code for this, we implement the ``Codegen`` method

llvm/trunk/docs/tutorial/LangImpl7.rst

 actually mutate the value! Okay, we have now officially implemented our
 goal: getting this to work requires SSA construction in the general
 case. However, to be really useful, we want the ability to define our
 own local variables, lets add this next!
 
 User-defined Local Variables
 ============================
 
-Adding var/in is just like any other other extensions we made to
+Adding var/in is just like any other extension we made to
 Kaleidoscope: we extend the lexer, the parser, the AST and the code
 generator. The first step for adding our new 'var/in' construct is to
 extend the lexer. As before, this is pretty trivial, the code looks like
 this:
 
 .. code-block:: c++
 
     enum Token {

llvm/trunk/include/llvm/Support/Options.h

 
 } // namespace detail
 
 /// \brief Singleton class used to register debug options.
 ///
 /// The OptionRegistry is responsible for managing lifetimes of the options and
 /// provides interfaces for option registration and reading values from options.
 /// This object is a singleton, only one instance should ever exist so that all
-/// options are registered in teh same place.
+/// options are registered in the same place.
 class OptionRegistry {
 private:
   DenseMap<void *, cl::Option *> Options;
 
   /// \brief Adds a cl::Option to the registry.
   ///
   /// \param Key unique key for option
   /// \param O option to map to \p Key

llvm/trunk/lib/Target/PowerPC/README_ALTIVEC.txt

This will generate the following instruction sequence:
         ori 2, 2, 0
         lxvd2x 35, 0, 3
         vaddudm 2, 2, 3
         blr
 
 This will almost certainly cause a load-hit-store hazard.  
 Since val is a value parameter, it should not need to be saved onto
 the stack, unless it's being done set up the vector register. Instead,
-it would be better to splat teh value into a vector register, and then
+it would be better to splat the value into a vector register, and then
 remove the (dead) stores to the stack.
 
 //===----------------------------------------------------------------------===//
 
 At the moment we always generate a lxsdx in preference to lfd, or stxsdx in
 preference to stfd.  When we have a reg-immediate addressing mode, this is a
 poor choice, since we have to load the address into an index register.  This
 should be fixed for P7/P8.