Fix documentation typos

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

docs/LLVMBuild.rst

@@ -315,7 +315,7 @@ the properties which are associated with that component.
 
    ``BuildTool`` components are like ``Tool`` components, except that the
    tool is supposed to be built for the platform where the build is running
-   (instead of that platform being targetted). Build systems are expected
+   (instead of that platform being targeted). Build systems are expected
    to handle the fact that required libraries may need to be built for
    multiple platforms in order to be able to link this tool.
 

docs/NVPTXUsage.rst

@@ -273,7 +273,7 @@ there is a separate version for each compute architecture.
 For a list of all math functions implemented in libdevice, see
 `libdevice Users Guide <http://docs.nvidia.com/cuda/libdevice-users-guide/index.html>`_.
 
-To accomodate various math-related compiler flags that can affect code
+To accommodate various math-related compiler flags that can affect code
 generation of libdevice code, the library code depends on a special LLVM IR
 pass (``NVVMReflect``) to handle conditional compilation within LLVM IR. This
 pass looks for calls to the ``@__nvvm_reflect`` function and replaces them

docs/TableGenFundamentals.rst

@@ -601,7 +601,7 @@ the classes multiple times yourself, e.g. by writing:
   ...
 
 A ``defm`` can also be used inside a multiclass providing several levels of
-multiclass instanciations.
+multiclass instantiations.
 
 .. code-block:: llvm
 
@@ -727,7 +727,7 @@ opened, as in the case with the ``CALL*`` instructions above.
 
 It's also possible to use "let" expressions inside multiclasses, providing more
 ways to factor out commonality from the records, specially if using several
-levels of multiclass instanciations. This also avoids the need of using "let"
+levels of multiclass instantiations. This also avoids the need of using "let"
 expressions within subsequent records inside a multiclass.
 
 .. code-block:: llvm

docs/YamlIO.rst

@@ -641,7 +641,7 @@ The YAML syntax supports tags as a way to specify the type of a node before
 it is parsed. This allows dynamic types of nodes.  But the YAML I/O model uses
 static typing, so there are limits to how you can use tags with the YAML I/O
 model. Recently, we added support to YAML I/O for checking/setting the optional 
-tag on a map. Using this functionality it is even possbile to support differnt 
+tag on a map. Using this functionality it is even possbile to support different 
 mappings, as long as they are convertable.  
 
 To check a tag, inside your mapping() method you can use io.mapTag() to specify

docs/doxygen.cfg.in

@@ -280,10 +280,10 @@ TYPEDEF_HIDES_STRUCT   = NO
 # For small to medium size projects (<1000 input files) the default value is
 # probably good enough. For larger projects a too small cache size can cause
 # doxygen to be busy swapping symbols to and from disk most of the time
-# causing a significant performance penality.
+# causing a significant performance penalty.
 # If the system has enough physical memory increasing the cache will improve the
 # performance by keeping more symbols in memory. Note that the value works on
-# a logarithmic scale so increasing the size by one will rougly double the
+# a logarithmic scale so increasing the size by one will roughly double the
 # memory usage. The cache size is given by this formula:
 # 2^(16+SYMBOL_CACHE_SIZE). The valid range is 0..9, the default is 0,
 # corresponding to a cache size of 2^16 = 65536 symbols