[llvm] f65d4aa - [llvm] NFC: fix trivial typos in documents
Jim Lin via llvm-commits
llvm-commits at lists.llvm.org
Tue Jan 21 19:29:32 PST 2020
Author: Kazuaki Ishizaki
Date: 2020-01-22T11:32:51+08:00
New Revision: f65d4aa96082778dc4af4657519d4d1aebbdf4da
URL: https://github.com/llvm/llvm-project/commit/f65d4aa96082778dc4af4657519d4d1aebbdf4da
DIFF: https://github.com/llvm/llvm-project/commit/f65d4aa96082778dc4af4657519d4d1aebbdf4da.diff
LOG: [llvm] NFC: fix trivial typos in documents
Reviewers: hans, Jim
Reviewed By: Jim
Subscribers: jvesely, nhaehnle, mgorny, arphaman, bmahjour, kerbowa, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D73017
Added:
Modified:
llvm/docs/AMDGPU/AMDGPUAsmGFX10.rst
llvm/docs/AMDGPU/AMDGPUAsmGFX7.rst
llvm/docs/AMDGPU/AMDGPUAsmGFX8.rst
llvm/docs/AMDGPU/AMDGPUAsmGFX9.rst
llvm/docs/AMDGPU/AMDGPUAsmGFX900.rst
llvm/docs/AMDGPU/AMDGPUAsmGFX904.rst
llvm/docs/AMDGPU/AMDGPUAsmGFX906.rst
llvm/docs/AMDGPU/AMDGPUAsmGFX908.rst
llvm/docs/Atomics.rst
llvm/docs/BigEndianNEON.rst
llvm/docs/BlockFrequencyTerminology.rst
llvm/docs/Bugpoint.rst
llvm/docs/CMakePrimer.rst
llvm/docs/CodeGenerator.rst
llvm/docs/CodingStandards.rst
llvm/docs/CommandGuide/lit.rst
llvm/docs/CommandGuide/tblgen.rst
llvm/docs/CompileCudaWithLLVM.rst
llvm/docs/CoverageMappingFormat.rst
llvm/docs/DependenceGraphs/index.rst
llvm/docs/DeveloperPolicy.rst
llvm/docs/Extensions.rst
llvm/docs/Frontend/PerformanceTips.rst
llvm/docs/FuzzingLLVM.rst
llvm/docs/GettingStarted.rst
llvm/docs/GlobalISel/GenericOpcode.rst
llvm/docs/GwpAsan.rst
llvm/docs/HowToBuildOnARM.rst
llvm/docs/HowToCrossCompileBuiltinsOnArm.rst
llvm/docs/LangRef.rst
llvm/docs/LibFuzzer.rst
llvm/docs/MarkedUpDisassembly.rst
llvm/docs/MemTagSanitizer.rst
llvm/docs/ORCv2.rst
llvm/docs/ProgrammersManual.rst
llvm/docs/Proposals/GitHubMove.rst
llvm/docs/Proposals/TestSuite.rst
llvm/docs/Proposals/VariableNames.rst
llvm/docs/ReleaseProcess.rst
llvm/docs/ReportingGuide.rst
llvm/docs/SourceLevelDebugging.rst
llvm/docs/TableGen/LangRef.rst
llvm/docs/TransformMetadata.rst
llvm/docs/XRayFDRFormat.rst
llvm/docs/YamlIO.rst
llvm/docs/tutorial/BuildingAJIT1.rst
llvm/docs/tutorial/BuildingAJIT2.rst
llvm/docs/tutorial/OCamlLangImpl3.rst
Removed:
################################################################################
diff --git a/llvm/docs/AMDGPU/AMDGPUAsmGFX10.rst b/llvm/docs/AMDGPU/AMDGPUAsmGFX10.rst
index bc2b4f74ecfe..d0f65ee6d89f 100644
--- a/llvm/docs/AMDGPU/AMDGPUAsmGFX10.rst
+++ b/llvm/docs/AMDGPU/AMDGPUAsmGFX10.rst
@@ -22,8 +22,8 @@ Notation
Notation used in this document is explained :ref:`here<amdgpu_syn_instruction_notation>`.
-Overvew
-=======
+Overview
+========
An overview of generic syntax and other features of AMDGPU instructions may be found :ref:`in this document<amdgpu_syn_instructions>`.
diff --git a/llvm/docs/AMDGPU/AMDGPUAsmGFX7.rst b/llvm/docs/AMDGPU/AMDGPUAsmGFX7.rst
index e96862bcf032..c1b8512367f8 100644
--- a/llvm/docs/AMDGPU/AMDGPUAsmGFX7.rst
+++ b/llvm/docs/AMDGPU/AMDGPUAsmGFX7.rst
@@ -22,8 +22,8 @@ Notation
Notation used in this document is explained :ref:`here<amdgpu_syn_instruction_notation>`.
-Overvew
-=======
+Overview
+========
An overview of generic syntax and other features of AMDGPU instructions may be found :ref:`in this document<amdgpu_syn_instructions>`.
diff --git a/llvm/docs/AMDGPU/AMDGPUAsmGFX8.rst b/llvm/docs/AMDGPU/AMDGPUAsmGFX8.rst
index 4dd0439c6fdb..b41d5e6eaf94 100644
--- a/llvm/docs/AMDGPU/AMDGPUAsmGFX8.rst
+++ b/llvm/docs/AMDGPU/AMDGPUAsmGFX8.rst
@@ -22,8 +22,8 @@ Notation
Notation used in this document is explained :ref:`here<amdgpu_syn_instruction_notation>`.
-Overvew
-=======
+Overview
+========
An overview of generic syntax and other features of AMDGPU instructions may be found :ref:`in this document<amdgpu_syn_instructions>`.
diff --git a/llvm/docs/AMDGPU/AMDGPUAsmGFX9.rst b/llvm/docs/AMDGPU/AMDGPUAsmGFX9.rst
index 7131718df7e7..9f17b34fc1a0 100644
--- a/llvm/docs/AMDGPU/AMDGPUAsmGFX9.rst
+++ b/llvm/docs/AMDGPU/AMDGPUAsmGFX9.rst
@@ -22,8 +22,8 @@ Notation
Notation used in this document is explained :ref:`here<amdgpu_syn_instruction_notation>`.
-Overvew
-=======
+Overview
+========
An overview of generic syntax and other features of AMDGPU instructions may be found :ref:`in this document<amdgpu_syn_instructions>`.
diff --git a/llvm/docs/AMDGPU/AMDGPUAsmGFX900.rst b/llvm/docs/AMDGPU/AMDGPUAsmGFX900.rst
index 7832e08dbb37..4e81f974ad73 100644
--- a/llvm/docs/AMDGPU/AMDGPUAsmGFX900.rst
+++ b/llvm/docs/AMDGPU/AMDGPUAsmGFX900.rst
@@ -24,8 +24,8 @@ Notation
Notation used in this document is explained :ref:`here<amdgpu_syn_instruction_notation>`.
-Overvew
-=======
+Overview
+========
An overview of generic syntax and other features of AMDGPU instructions may be found :ref:`in this document<amdgpu_syn_instructions>`.
diff --git a/llvm/docs/AMDGPU/AMDGPUAsmGFX904.rst b/llvm/docs/AMDGPU/AMDGPUAsmGFX904.rst
index 23f79fc96a43..230d689f3a0e 100644
--- a/llvm/docs/AMDGPU/AMDGPUAsmGFX904.rst
+++ b/llvm/docs/AMDGPU/AMDGPUAsmGFX904.rst
@@ -24,8 +24,8 @@ Notation
Notation used in this document is explained :ref:`here<amdgpu_syn_instruction_notation>`.
-Overvew
-=======
+Overview
+========
An overview of generic syntax and other features of AMDGPU instructions may be found :ref:`in this document<amdgpu_syn_instructions>`.
diff --git a/llvm/docs/AMDGPU/AMDGPUAsmGFX906.rst b/llvm/docs/AMDGPU/AMDGPUAsmGFX906.rst
index 8119af4392eb..ee9c45d65c92 100644
--- a/llvm/docs/AMDGPU/AMDGPUAsmGFX906.rst
+++ b/llvm/docs/AMDGPU/AMDGPUAsmGFX906.rst
@@ -24,8 +24,8 @@ Notation
Notation used in this document is explained :ref:`here<amdgpu_syn_instruction_notation>`.
-Overvew
-=======
+Overview
+========
An overview of generic syntax and other features of AMDGPU instructions may be found :ref:`in this document<amdgpu_syn_instructions>`.
diff --git a/llvm/docs/AMDGPU/AMDGPUAsmGFX908.rst b/llvm/docs/AMDGPU/AMDGPUAsmGFX908.rst
index 7e90837cdf0b..bae8f7701a0a 100644
--- a/llvm/docs/AMDGPU/AMDGPUAsmGFX908.rst
+++ b/llvm/docs/AMDGPU/AMDGPUAsmGFX908.rst
@@ -24,8 +24,8 @@ Notation
Notation used in this document is explained :ref:`here<amdgpu_syn_instruction_notation>`.
-Overvew
-=======
+Overview
+========
An overview of generic syntax and other features of AMDGPU instructions may be found :ref:`in this document<amdgpu_syn_instructions>`.
diff --git a/llvm/docs/Atomics.rst b/llvm/docs/Atomics.rst
index 00f29c285b3f..7d57740ded7c 100644
--- a/llvm/docs/Atomics.rst
+++ b/llvm/docs/Atomics.rst
@@ -562,7 +562,7 @@ various reasons, it is not practical to emit the instructions inline.
There's two typical examples of this.
-Some CPUs support multiple instruction sets which can be swiched back and forth
+Some CPUs support multiple instruction sets which can be switched back and forth
on function-call boundaries. For example, MIPS supports the MIPS16 ISA, which
has a smaller instruction encoding than the usual MIPS32 ISA. ARM, similarly,
has the Thumb ISA. In MIPS16 and earlier versions of Thumb, the atomic
diff --git a/llvm/docs/BigEndianNEON.rst b/llvm/docs/BigEndianNEON.rst
index 242eb0e73d2f..aa564c14dee6 100644
--- a/llvm/docs/BigEndianNEON.rst
+++ b/llvm/docs/BigEndianNEON.rst
@@ -12,7 +12,7 @@ Generating code for big endian ARM processors is for the most part straightforwa
The aim of this document is to explain the problem with NEON loads and stores, and the solution that has been implemented in LLVM.
-In this document the term "vector" refers to what the ARM ABI calls a "short vector", which is a sequence of items that can fit in a NEON register. This sequence can be 64 or 128 bits in length, and can constitute 8, 16, 32 or 64 bit items. This document refers to A64 instructions throughout, but is almost applicable to the A32/ARMv7 instruction sets also. The ABI format for passing vectors in A32 is sligtly
diff erent to A64. Apart from that, the same concepts apply.
+In this document the term "vector" refers to what the ARM ABI calls a "short vector", which is a sequence of items that can fit in a NEON register. This sequence can be 64 or 128 bits in length, and can constitute 8, 16, 32 or 64 bit items. This document refers to A64 instructions throughout, but is almost applicable to the A32/ARMv7 instruction sets also. The ABI format for passing vectors in A32 is slightly
diff erent to A64. Apart from that, the same concepts apply.
Example: C-level intrinsics -> assembly
---------------------------------------
diff --git a/llvm/docs/BlockFrequencyTerminology.rst b/llvm/docs/BlockFrequencyTerminology.rst
index 41f89f8ce965..a424be2aa7f8 100644
--- a/llvm/docs/BlockFrequencyTerminology.rst
+++ b/llvm/docs/BlockFrequencyTerminology.rst
@@ -82,7 +82,7 @@ by a cut edge should equal ``UINT64_MAX``. In other words, mass is conserved
as it "falls" through the DAG.
If a function's basic block graph is a DAG, then block masses are valid block
-frequencies. This works poorly in practise though, since downstream users rely
+frequencies. This works poorly in practice though, since downstream users rely
on adding block frequencies together without hitting the maximum.
Loop Scale
diff --git a/llvm/docs/Bugpoint.rst b/llvm/docs/Bugpoint.rst
index 19efaf2bdee7..2dd504520d50 100644
--- a/llvm/docs/Bugpoint.rst
+++ b/llvm/docs/Bugpoint.rst
@@ -121,7 +121,7 @@ non-obvious ways. Here are some hints and tips:
miscompilation. Programs should be temporarily modified to disable outputs
that are likely to vary from run to run.
-* In the `crash debugger`_, ``bugpoint`` does not distiguish
diff erent crashes
+* In the `crash debugger`_, ``bugpoint`` does not distinguish
diff erent crashes
during reduction. Thus, if new crash or miscompilation happens, ``bugpoint``
will continue with the new crash instead. If you would like to stick to
particular crash, you should write check scripts to validate the error
diff --git a/llvm/docs/CMakePrimer.rst b/llvm/docs/CMakePrimer.rst
index 72ebffa5bdd6..abfd08017fbf 100644
--- a/llvm/docs/CMakePrimer.rst
+++ b/llvm/docs/CMakePrimer.rst
@@ -333,7 +333,7 @@ When defining a CMake command handling arguments is very useful. The examples
in this section will all use the CMake ``function`` block, but this all applies
to the ``macro`` block as well.
-CMake commands can have named arguments that are requried at every call site. In
+CMake commands can have named arguments that are required at every call site. In
addition, all commands will implicitly accept a variable number of extra
arguments (In C parlance, all commands are varargs functions). When a command is
invoked with extra arguments (beyond the named ones) CMake will store the full
diff --git a/llvm/docs/CodeGenerator.rst b/llvm/docs/CodeGenerator.rst
index e38464a0f80f..875a96ca4e2a 100644
--- a/llvm/docs/CodeGenerator.rst
+++ b/llvm/docs/CodeGenerator.rst
@@ -1272,7 +1272,7 @@ compatible with a given physical, this code can be used:
Sometimes, mostly for debugging purposes, it is useful to change the number of
physical registers available in the target architecture. This must be done
-statically, inside the ``TargetRegsterInfo.td`` file. Just ``grep`` for
+statically, inside the ``TargetRegisterInfo.td`` file. Just ``grep`` for
``RegisterClass``, the last parameter of which is a list of registers. Just
commenting some out is one simple way to avoid them being used. A more polite
way is to explicitly exclude some registers from the *allocation order*. See the
@@ -2418,7 +2418,7 @@ to spill registers r3-r10. This allows callees blind to the call signature,
such as thunks and vararg functions, enough space to cache the argument
registers. Therefore, the parameter area is minimally 32 bytes (64 bytes in 64
bit mode.) Also note that since the parameter area is a fixed offset from the
-top of the frame, that a callee can access its spilt arguments using fixed
+top of the frame, that a callee can access its split arguments using fixed
offsets from the stack pointer (or base pointer.)
Combining the information about the linkage, parameter areas and alignment. A
diff --git a/llvm/docs/CodingStandards.rst b/llvm/docs/CodingStandards.rst
index 0478bd270789..394b1c602e05 100644
--- a/llvm/docs/CodingStandards.rst
+++ b/llvm/docs/CodingStandards.rst
@@ -647,7 +647,7 @@ Beware of non-deterministic sorting order of equal elements
``std::sort`` uses a non-stable sorting algorithm in which the order of equal
elements is not guaranteed to be preserved. Thus using ``std::sort`` for a
-container having equal elements may result in non-determinstic behavior.
+container having equal elements may result in non-deterministic behavior.
To uncover such instances of non-determinism, LLVM has introduced a new
llvm::sort wrapper function. For an EXPENSIVE_CHECKS build this will randomly
shuffle the container before sorting. Default to using ``llvm::sort`` instead
@@ -1206,7 +1206,7 @@ Don't evaluate ``end()`` every time through a loop
In cases where range-based ``for`` loops can't be used and it is necessary
to write an explicit iterator-based loop, pay close attention to whether
-``end()`` is re-evaluted on each loop iteration. One common mistake is to
+``end()`` is re-evaluated on each loop iteration. One common mistake is to
write a loop in this style:
.. code-block:: c++
diff --git a/llvm/docs/CommandGuide/lit.rst b/llvm/docs/CommandGuide/lit.rst
index 40aeecdf2c81..ebc0bf2c27fd 100644
--- a/llvm/docs/CommandGuide/lit.rst
+++ b/llvm/docs/CommandGuide/lit.rst
@@ -176,7 +176,7 @@ SELECTION OPTIONS
"shards", and run only one of them. Must be used with the
``--run-shard=N`` option, which selects the shard to run. The environment
variable ``LIT_NUM_SHARDS`` can also be used in place of this
- option. These two options provide a coarse mechanism for paritioning large
+ option. These two options provide a coarse mechanism for partitioning large
testsuites, for parallel execution on separate machines (say in a large
testing farm).
diff --git a/llvm/docs/CommandGuide/tblgen.rst b/llvm/docs/CommandGuide/tblgen.rst
index 372d1b2a7308..2a468fa95fdd 100644
--- a/llvm/docs/CommandGuide/tblgen.rst
+++ b/llvm/docs/CommandGuide/tblgen.rst
@@ -98,7 +98,7 @@ OPTIONS
.. option:: -gen-dag-isel
- Generate a DAG (Directed Acycle Graph) instruction selector.
+ Generate a DAG (Directed Acyclic Graph) instruction selector.
.. option:: -gen-asm-matcher
diff --git a/llvm/docs/CompileCudaWithLLVM.rst b/llvm/docs/CompileCudaWithLLVM.rst
index 6e181c84e688..b4479771f803 100644
--- a/llvm/docs/CompileCudaWithLLVM.rst
+++ b/llvm/docs/CompileCudaWithLLVM.rst
@@ -512,7 +512,7 @@ LLVM to make it generate good GPU code. Among these changes are:
* `Memory space inference
<http://llvm.org/doxygen/NVPTXInferAddressSpaces_8cpp_source.html>`_ --
- In PTX, we can operate on pointers that are in a paricular "address space"
+ In PTX, we can operate on pointers that are in a particular "address space"
(global, shared, constant, or local), or we can operate on pointers in the
"generic" address space, which can point to anything. Operations in a
non-generic address space are faster, but pointers in CUDA are not explicitly
@@ -528,7 +528,7 @@ LLVM to make it generate good GPU code. Among these changes are:
which fit in 32-bits at runtime. This optimization provides a fast path for
this common case.
-* Aggressive loop unrooling and function inlining -- Loop unrolling and
+* Aggressive loop unrolling and function inlining -- Loop unrolling and
function inlining need to be more aggressive for GPUs than for CPUs because
control flow transfer in GPU is more expensive. More aggressive unrolling and
inlining also promote other optimizations, such as constant propagation and
diff --git a/llvm/docs/CoverageMappingFormat.rst b/llvm/docs/CoverageMappingFormat.rst
index 30b11fe2f31d..133c63418ac4 100644
--- a/llvm/docs/CoverageMappingFormat.rst
+++ b/llvm/docs/CoverageMappingFormat.rst
@@ -12,7 +12,7 @@ Introduction
============
LLVM's code coverage mapping format is used to provide code coverage
-analysis using LLVM's and Clang's instrumenation based profiling
+analysis using LLVM's and Clang's instrumentation based profiling
(Clang's ``-fprofile-instr-generate`` option).
This document is aimed at those who use LLVM's code coverage mapping to provide
diff --git a/llvm/docs/DependenceGraphs/index.rst b/llvm/docs/DependenceGraphs/index.rst
index c53ee9051d5f..e3e6447df2f6 100644
--- a/llvm/docs/DependenceGraphs/index.rst
+++ b/llvm/docs/DependenceGraphs/index.rst
@@ -131,7 +131,7 @@ graph described in [1]_ in the following ways:
1. The graph nodes in the paper represent three main program components, namely *assignment statements*, *for loop headers* and *while loop headers*. In this implementation, DDG nodes naturally represent LLVM IR instructions. An assignment statement in this implementation typically involves a node representing the ``store`` instruction along with a number of individual nodes computing the right-hand-side of the assignment that connect to the ``store`` node via a def-use edge. The loop header instructions are not represented as special nodes in this implementation because they have limited uses and can be easily identified, for example, through ``LoopAnalysis``.
2. The paper describes five types of dependency edges between nodes namely *loop dependency*, *flow-*, *anti-*, *output-*, and *input-* dependencies. In this implementation *memory* edges represent the *flow-*, *anti-*, *output-*, and *input-* dependencies. However, *loop dependencies* are not made explicit, because they mainly represent association between a loop structure and the program elements inside the loop and this association is fairly obvious in LLVM IR itself.
- 3. The paper describes two types of pi-blocks; *recurrences* whose bodies are SCCs and *IN* nodes whose bodies are not part of any SCC. In this impelmentation, pi-blocks are only created for *recurrences*. *IN* nodes remain as simple DDG nodes in the graph.
+ 3. The paper describes two types of pi-blocks; *recurrences* whose bodies are SCCs and *IN* nodes whose bodies are not part of any SCC. In this implementation, pi-blocks are only created for *recurrences*. *IN* nodes remain as simple DDG nodes in the graph.
References
diff --git a/llvm/docs/DeveloperPolicy.rst b/llvm/docs/DeveloperPolicy.rst
index b31ef42c15db..c4d0ceb73c8e 100644
--- a/llvm/docs/DeveloperPolicy.rst
+++ b/llvm/docs/DeveloperPolicy.rst
@@ -384,8 +384,8 @@ after they are committed, depending on the nature of the change). You are
encouraged to review other peoples' patches as well, but you aren't required
to do so.
-Current Contributors - Transfering from SVN
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Current Contributors - Transferring from SVN
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
If you had commit access to SVN and would like to request commit access to
GitHub, please email `llvm-admin <mailto:llvm-admin at lists.llvm.org>`_ with your
SVN username and GitHub username.
@@ -744,7 +744,7 @@ OpenMP, etc), Polly, and all other subprojects. There are a few exceptions:
is used by LLVM.
* Some subprojects are impractical or uninteresting to relicense (e.g. llvm-gcc
and dragonegg). These will be split off from the LLVM project (e.g. to
- separate Github projects), allowing interested people to continue their
+ separate GitHub projects), allowing interested people to continue their
development elsewhere.
To relicense LLVM, we will be seeking approval from all of the copyright holders
@@ -875,7 +875,7 @@ holds though)::
Q2: If at any time after my contribution, I am able to license other patent
claims that would have been subject to Apache's Grant of Patent License if
- they were licenseable by me at the time of my contribution, do those other
+ they were licensable by me at the time of my contribution, do those other
claims become subject to the Grant of Patent License?
A2: Yes.
diff --git a/llvm/docs/Extensions.rst b/llvm/docs/Extensions.rst
index e6f7fdd50447..4062d2088fec 100644
--- a/llvm/docs/Extensions.rst
+++ b/llvm/docs/Extensions.rst
@@ -213,7 +213,7 @@ ELF-Dependent
^^^^^^^^^^^^^^^^^^^^^^
In order to support creating multiple sections with the same name and comdat,
-it is possible to add an unique number at the end of the ``.seciton`` directive.
+it is possible to add an unique number at the end of the ``.section`` directive.
For example, the following code creates two sections named ``.text``.
.. code-block:: gas
diff --git a/llvm/docs/Frontend/PerformanceTips.rst b/llvm/docs/Frontend/PerformanceTips.rst
index f0f63f3f9d6b..7873087a14f0 100644
--- a/llvm/docs/Frontend/PerformanceTips.rst
+++ b/llvm/docs/Frontend/PerformanceTips.rst
@@ -255,7 +255,7 @@ couple specific suggestions:
#. For languages with numerous rarely executed guard conditions (e.g. null
checks, type checks, range checks) consider adding an extra execution or
- two of LoopUnswith and LICM to your pass order. The standard pass order,
+ two of LoopUnswitch and LICM to your pass order. The standard pass order,
which is tuned for C and C++ applications, may not be sufficient to remove
all dischargeable checks from loops.
diff --git a/llvm/docs/FuzzingLLVM.rst b/llvm/docs/FuzzingLLVM.rst
index ab4b9b557cde..e471020aab76 100644
--- a/llvm/docs/FuzzingLLVM.rst
+++ b/llvm/docs/FuzzingLLVM.rst
@@ -106,7 +106,7 @@ llvm-opt-fuzzer
A |LLVM IR fuzzer| aimed at finding bugs in optimization passes.
-It receives optimzation pipeline and runs it for each fuzzer input.
+It receives optimization pipeline and runs it for each fuzzer input.
Interface of this fuzzer almost directly mirrors ``llvm-isel-fuzzer``. Both
``mtriple`` and ``passes`` arguments are required. Passes are specified in a
diff --git a/llvm/docs/GettingStarted.rst b/llvm/docs/GettingStarted.rst
index 35c021ee3209..8a5476fd924f 100644
--- a/llvm/docs/GettingStarted.rst
+++ b/llvm/docs/GettingStarted.rst
@@ -599,7 +599,7 @@ used by people developing LLVM.
| | overridden with ``LLVM_DYLIB_COMPONENTS``. The |
| | default contains most of LLVM and is defined in |
| | ``tools/llvm-shlib/CMakelists.txt``. This option is|
-| | not avialable on Windows. |
+| | not available on Windows. |
+-------------------------+----------------------------------------------------+
| LLVM_OPTIMIZED_TABLEGEN | Builds a release tablegen that gets used during |
| | the LLVM build. This can dramatically speed up |
diff --git a/llvm/docs/GlobalISel/GenericOpcode.rst b/llvm/docs/GlobalISel/GenericOpcode.rst
index 5cc1023db235..3c083a523a61 100644
--- a/llvm/docs/GlobalISel/GenericOpcode.rst
+++ b/llvm/docs/GlobalISel/GenericOpcode.rst
@@ -633,7 +633,7 @@ G_INTRINSIC, G_INTRINSIC_W_SIDE_EFFECTS
Call an intrinsic
The _W_SIDE_EFFECTS version is considered to have unknown side-effects and
-as such cannot be reordered acrosss other side-effecting instructions.
+as such cannot be reordered across other side-effecting instructions.
.. note::
diff --git a/llvm/docs/GwpAsan.rst b/llvm/docs/GwpAsan.rst
index 67193bfe001f..647c2a038a5a 100644
--- a/llvm/docs/GwpAsan.rst
+++ b/llvm/docs/GwpAsan.rst
@@ -55,7 +55,7 @@ Allocator Support
GWP-ASan is not a replacement for a traditional allocator. Instead, it works by
inserting stubs into a supporting allocator to redirect allocations to GWP-ASan
when they're chosen to be sampled. These stubs are generally implemented in the
-implementaion of ``malloc()``, ``free()`` and ``realloc()``. The stubs are
+implementation of ``malloc()``, ``free()`` and ``realloc()``. The stubs are
extremely small, which makes using GWP-ASan in most allocators fairly trivial.
The stubs follow the same general pattern (example ``malloc()`` pseudocode
below):
diff --git a/llvm/docs/HowToBuildOnARM.rst b/llvm/docs/HowToBuildOnARM.rst
index 356c846d82bc..f28f8b3ae2d5 100644
--- a/llvm/docs/HowToBuildOnARM.rst
+++ b/llvm/docs/HowToBuildOnARM.rst
@@ -22,7 +22,7 @@ on the ARMv6 and ARMv7 architectures and may be inapplicable to older chips.
Pandaboard, have become hard-float platforms. There are a number of
choices when using CMake. Autoconf usage is deprecated as of 3.8.
- Building LLVM/Clang in ``Relese`` mode is preferred since it consumes
+ Building LLVM/Clang in ``Release`` mode is preferred since it consumes
a lot less memory. Otherwise, the building process will very likely
fail due to insufficient memory. It's also a lot quicker to only build
the relevant back-ends (ARM and AArch64), since it's very unlikely that
@@ -42,7 +42,7 @@ on the ARMv6 and ARMv7 architectures and may be inapplicable to older chips.
Use Ninja instead of Make: "-G Ninja"
Build with assertions on: "-DLLVM_ENABLE_ASSERTIONS=True"
Force Python2: "-DPYTHON_EXECUTABLE=/usr/bin/python2"
- Local (non-sudo) install path: "-DCMAKE_INSTALL_PREFIX=$HOME/llvm/instal"
+ Local (non-sudo) install path: "-DCMAKE_INSTALL_PREFIX=$HOME/llvm/install"
CPU flags: "DCMAKE_C_FLAGS=-mcpu=cortex-a15" (same for CXX_FLAGS)
After that, just typing ``make -jN`` or ``ninja`` will build everything.
diff --git a/llvm/docs/HowToCrossCompileBuiltinsOnArm.rst b/llvm/docs/HowToCrossCompileBuiltinsOnArm.rst
index 6ad93c773b25..72dfea4eb687 100644
--- a/llvm/docs/HowToCrossCompileBuiltinsOnArm.rst
+++ b/llvm/docs/HowToCrossCompileBuiltinsOnArm.rst
@@ -43,7 +43,7 @@ compiler-rt must be placed in the runtimes directory.
``qemu-arm`` should be available as a package for your Linux distribution.
-The most complicated of the prequisites to satisfy is the arm-linux-gnueabihf
+The most complicated of the prerequisites to satisfy is the arm-linux-gnueabihf
sysroot. In theory it is possible to use the Linux distributions multiarch
support to fulfill the dependencies for building but unfortunately due to
/usr/local/include being added some host includes are selected. The easiest way
diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index ce1fb17cbac5..907440006828 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -4866,9 +4866,9 @@ refines this address to produce a concrete location for the source variable.
A ``llvm.dbg.value`` intrinsic describes the direct value of a source variable.
The first operand of the intrinsic may be a direct or indirect value. A
-DIExpresion attached to the intrinsic refines the first operand to produce a
+DIExpression attached to the intrinsic refines the first operand to produce a
direct value. For example, if the first operand is an indirect value, it may be
-necessary to insert ``DW_OP_deref`` into the DIExpresion in order to produce a
+necessary to insert ``DW_OP_deref`` into the DIExpression in order to produce a
valid debug intrinsic.
.. note::
@@ -6349,7 +6349,7 @@ The list is encoded in the IR using named metadata with the name
``!llvm.dependent-libraries``. Each operand is expected to be a metadata node
which should contain a single string operand.
-For example, the following metadata section contains two library specfiers::
+For example, the following metadata section contains two library specifiers::
!0 = !{!"a library specifier"}
!1 = !{!"another library specifier"}
@@ -15138,7 +15138,7 @@ This is an overloaded intrinsic. Several values of integer, floating point or po
Overview:
"""""""""
-Reads a number of scalar values sequentially from memory location provided in '``ptr``' and spreads them in a vector. The '``mask``' holds a bit for each vector lane. The number of elements read from memory is equal to the number of '1' bits in the mask. The loaded elements are positioned in the destination vector according to the sequence of '1' and '0' bits in the mask. E.g., if the mask vector is '10010001', "explandload" reads 3 values from memory addresses ptr, ptr+1, ptr+2 and places them in lanes 0, 3 and 7 accordingly. The masked-off lanes are filled by elements from the corresponding lanes of the '``passthru``' operand.
+Reads a number of scalar values sequentially from memory location provided in '``ptr``' and spreads them in a vector. The '``mask``' holds a bit for each vector lane. The number of elements read from memory is equal to the number of '1' bits in the mask. The loaded elements are positioned in the destination vector according to the sequence of '1' and '0' bits in the mask. E.g., if the mask vector is '10010001', "expandload" reads 3 values from memory addresses ptr, ptr+1, ptr+2 and places them in lanes 0, 3 and 7 accordingly. The masked-off lanes are filled by elements from the corresponding lanes of the '``passthru``' operand.
Arguments:
diff --git a/llvm/docs/LibFuzzer.rst b/llvm/docs/LibFuzzer.rst
index 9ab013e721e1..8196bc52e90b 100644
--- a/llvm/docs/LibFuzzer.rst
+++ b/llvm/docs/LibFuzzer.rst
@@ -287,7 +287,7 @@ The most important command line options are:
that trigger new code coverage will be merged into the first corpus
directory. Defaults to 0. This flag can be used to minimize a corpus.
``-merge_control_file``
- Specify a control file used for the merge proccess.
+ Specify a control file used for the merge process.
If a merge process gets killed it tries to leave this file in a state
suitable for resuming the merge. By default a temporary file will be used.
``-minimize_crash``
@@ -515,7 +515,7 @@ and extra run-time flag ``-use_value_profile=1`` the fuzzer will
collect value profiles for the parameters of compare instructions
and treat some new values as new coverage.
-The current imlpementation does roughly the following:
+The current implementation does roughly the following:
* The compiler instruments all CMP instructions with a callback that receives both CMP arguments.
* The callback computes `(caller_pc&4095) | (popcnt(Arg1 ^ Arg2) << 12)` and uses this value to set a bit in a bitset.
diff --git a/llvm/docs/MarkedUpDisassembly.rst b/llvm/docs/MarkedUpDisassembly.rst
index df8befe45cd0..05feee158e12 100644
--- a/llvm/docs/MarkedUpDisassembly.rst
+++ b/llvm/docs/MarkedUpDisassembly.rst
@@ -41,7 +41,7 @@ Instruction Annotations
Contextual markups
------------------
-Annoated assembly display will supply contextual markup to help clients more
+Annotated assembly display will supply contextual markup to help clients more
efficiently implement things like pretty printers. Most markup will be target
independent, so clients can effectively provide good display without any target
specific knowledge.
diff --git a/llvm/docs/MemTagSanitizer.rst b/llvm/docs/MemTagSanitizer.rst
index a27370368b46..988c11b69bf6 100644
--- a/llvm/docs/MemTagSanitizer.rst
+++ b/llvm/docs/MemTagSanitizer.rst
@@ -37,7 +37,7 @@ Implementation
==============
See `HardwareAssistedAddressSanitizer`_ for a general overview of a
-tag-based approach to memory safety. MemTagSanitizer followes a
+tag-based approach to memory safety. MemTagSanitizer follows a
similar implementation strategy, but with the tag storage (shadow)
provided by the hardware.
diff --git a/llvm/docs/ORCv2.rst b/llvm/docs/ORCv2.rst
index 488ce262ee30..d1faaaa8fde6 100644
--- a/llvm/docs/ORCv2.rst
+++ b/llvm/docs/ORCv2.rst
@@ -124,7 +124,7 @@ module ``M`` loaded on a ThreadSafeContext ``Ctx``:
// Call into JIT'd code.
Entry();
-The builder clasess provide a number of configuration options that can be
+The builder classes provide a number of configuration options that can be
specified before the JIT instance is constructed. For example:
.. code-block:: c++
@@ -483,7 +483,7 @@ to be aware of:
references are resolved, and symbol resolvers are no longer used. See the
section `Design Overview`_ for more details.
- Unless multiple JITDylibs are needed to model linkage relationsips, ORCv1
+ Unless multiple JITDylibs are needed to model linkage relationships, ORCv1
clients should place all code in the main JITDylib (returned by
``ExecutionSession::getMainJITDylib()``). MCJIT clients should use LLJIT
(see `LLJIT and LLLazyJIT`_).
diff --git a/llvm/docs/ProgrammersManual.rst b/llvm/docs/ProgrammersManual.rst
index a96f8b4b714c..e4fb8615d759 100644
--- a/llvm/docs/ProgrammersManual.rst
+++ b/llvm/docs/ProgrammersManual.rst
@@ -2996,7 +2996,7 @@ proper operation in multithreaded mode.
Note that, on Unix-like platforms, LLVM requires the presence of GCC's atomic
intrinsics in order to support threaded operation. If you need a
-multhreading-capable LLVM on a platform without a suitably modern system
+multithreading-capable LLVM on a platform without a suitably modern system
compiler, consider compiling LLVM and LLVM-GCC in single-threaded mode, and
using the resultant compiler to build a copy of LLVM with multithreading
support.
@@ -3307,7 +3307,7 @@ place the ``vptr`` in the first word of the instances.)
.. _polymorphism:
-Designing Type Hiercharies and Polymorphic Interfaces
+Designing Type Hierarchies and Polymorphic Interfaces
-----------------------------------------------------
There are two
diff erent design patterns that tend to result in the use of
@@ -3351,7 +3351,7 @@ by Sean Parent in several of his talks and papers:
describing this technique in more detail.
#. `Sean Parent's Papers and Presentations
<http://github.com/sean-parent/sean-parent.github.com/wiki/Papers-and-Presentations>`_
- - A Github project full of links to slides, video, and sometimes code.
+ - A GitHub project full of links to slides, video, and sometimes code.
When deciding between creating a type hierarchy (with either tagged or virtual
dispatch) and using templates or concepts-based polymorphism, consider whether
@@ -3400,7 +3400,7 @@ The Core LLVM Class Hierarchy Reference
header source: `Type.h <http://llvm.org/doxygen/Type_8h_source.html>`_
-doxygen info: `Type Clases <http://llvm.org/doxygen/classllvm_1_1Type.html>`_
+doxygen info: `Type Classes <http://llvm.org/doxygen/classllvm_1_1Type.html>`_
The Core LLVM classes are the primary means of representing the program being
inspected or transformed. The core LLVM classes are defined in header files in
diff --git a/llvm/docs/Proposals/GitHubMove.rst b/llvm/docs/Proposals/GitHubMove.rst
index ed46f5ae199f..ae799b57af79 100644
--- a/llvm/docs/Proposals/GitHubMove.rst
+++ b/llvm/docs/Proposals/GitHubMove.rst
@@ -202,14 +202,14 @@ Step #4 : Post Move
14. Update links on the LLVM website pointing to viewvc/klaus/phab etc. to
point to GitHub instead.
-Github Repository Description
+GitHub Repository Description
=============================
Monorepo
----------------
The LLVM git repository hosted at https://github.com/llvm/llvm-project contains all
-sub-projects in a single source tree. It is often refered to as a monorepo and
+sub-projects in a single source tree. It is often referred to as a monorepo and
mimics an export of the current SVN repository, with each sub-project having its
own top-level directory. Not all sub-projects are used for building toolchains.
For example, www/ and test-suite/ are not part of the monorepo.
@@ -281,7 +281,7 @@ Monorepo Drawbacks
1GB for the monorepo), and the commit rate of LLVM may cause more frequent
`git push` collisions when upstreaming. Affected contributors may be able to
use the SVN bridge or the single-subproject Git mirrors. However, it's
- undecided if these projects will continue to be mantained.
+ undecided if these projects will continue to be maintained.
* Using the monolithic repository may add overhead for those *integrating* a
standalone sub-project, even if they aren't contributing to it, due to the
same disk space concern as the point above. The availability of the
@@ -356,7 +356,7 @@ Before you push, you'll need to fetch and rebase (`git pull --rebase`) as
usual.
Note that when you fetch you'll likely pull in changes to sub-projects you don't
-care about. If you are using spasre checkout, the files from other projects
+care about. If you are using sparse checkout, the files from other projects
won't appear on your disk. The only effect is that your commit hash changes.
You can check whether the changes in the last fetch are relevant to your commit
@@ -657,7 +657,7 @@ done for each branch. Ref paths will need to be updated to map the
local branch to the corresponding upstream branch. If local branches
have no corresponding upstream branch, then the creation of
``local/octopus/<local branch>`` need not use ``git-merge-base`` to
-pinpont its root commit; it may simply be branched from the
+pinpoint its root commit; it may simply be branched from the
appropriate component branch (say, ``llvm/local_release_X``).
Zipping local history
@@ -812,7 +812,7 @@ The tool handles nested submodules (e.g. llvm is a submodule in
umbrella and clang is a submodule in llvm). The file
``submodule-map.txt`` is a list of pairs, one per line. The first
pair item describes the path to a submodule in the umbrella
-repository. The second pair item secribes the path where trees for
+repository. The second pair item describes the path where trees for
that submodule should be written in the zipped history.
Let's say your umbrella repository is actually the llvm repository and
@@ -945,7 +945,7 @@ getting them into the monorepo. A recipe follows::
--tag-prefix="myrepo-"
)
- # Preserve release braches.
+ # Preserve release branches.
for ref in $(git -C my-monorepo for-each-ref --format="%(refname)" \
refs/remotes/myrepo/release); do
branch=${ref#refs/remotes/myrepo/}
diff --git a/llvm/docs/Proposals/TestSuite.rst b/llvm/docs/Proposals/TestSuite.rst
index 85f3642a2e92..29507495c116 100644
--- a/llvm/docs/Proposals/TestSuite.rst
+++ b/llvm/docs/Proposals/TestSuite.rst
@@ -1,5 +1,5 @@
=====================
-Test-Suite Extentions
+Test-Suite Extensions
=====================
.. contents::
@@ -191,7 +191,7 @@ CORAL-2 Benchmarks
------------------
https://asc.llnl.gov/coral-2-benchmarks/
-Many of its programs have already been integreated in
+Many of its programs have already been integrated in
MultiSource/Benchmarks/DOE-ProxyApps-C and
MultiSource/Benchmarks/DOE-ProxyApps-C++.
diff --git a/llvm/docs/Proposals/VariableNames.rst b/llvm/docs/Proposals/VariableNames.rst
index 3e07fc5606de..1739695a5185 100644
--- a/llvm/docs/Proposals/VariableNames.rst
+++ b/llvm/docs/Proposals/VariableNames.rst
@@ -153,7 +153,7 @@ TargetRegisterInfo tri
In some cases renaming acronyms to the full type name will result in overly
verbose code. Unlike most classes, a variable's scope is limited and therefore
some of its purpose can implied from that scope, meaning that fewer words are
-necessary to give it a clear name. For example, in an optization pass the reader
+necessary to give it a clear name. For example, in an optimization pass the reader
can assume that a variable's purpose relates to optimization and therefore an
``OptimizationRemarkEmitter`` variable could be given the name ``remarkEmitter``
or even ``remarker``.
diff --git a/llvm/docs/ReleaseProcess.rst b/llvm/docs/ReleaseProcess.rst
index 0cd455fdb79a..6a14e28d189a 100644
--- a/llvm/docs/ReleaseProcess.rst
+++ b/llvm/docs/ReleaseProcess.rst
@@ -204,7 +204,7 @@ and that will be the official binary.
* Rename (or link) ``clang+llvm-REL-ARCH-ENV`` to the .install directory
-* Tar that into the same name with ``.tar.gz`` extensioan from outside the
+* Tar that into the same name with ``.tar.gz`` extension from outside the
directory
* Make it available for the release manager to download
diff --git a/llvm/docs/ReportingGuide.rst b/llvm/docs/ReportingGuide.rst
index f7ecbb38d45e..ad2a035e8647 100644
--- a/llvm/docs/ReportingGuide.rst
+++ b/llvm/docs/ReportingGuide.rst
@@ -102,7 +102,7 @@ appropriateness of our response, but we don't guarantee we'll act on it.
After any incident, the advisory committee will make a report on the situation
to the LLVM Foundation board. The board may choose to make a public statement
about the incident. If that's the case, the identities of anyone involved will
-remain confidential unless instructed by those inviduals otherwise.
+remain confidential unless instructed by those individuals otherwise.
Appealing
=========
@@ -114,7 +114,7 @@ the case.
In general, it is **not** appropriate to appeal a particular decision on
a public mailing list. Doing so would involve disclosure of information which
-whould be confidential. Disclosing this kind of information publicly may be
+would be confidential. Disclosing this kind of information publicly may be
considered a separate and (potentially) more serious violation of the Code of
Conduct. This is not meant to limit discussion of the Code of Conduct, the
advisory board itself, or the appropriateness of responses in general, but
diff --git a/llvm/docs/SourceLevelDebugging.rst b/llvm/docs/SourceLevelDebugging.rst
index f6db104a0755..3be01eeb795c 100644
--- a/llvm/docs/SourceLevelDebugging.rst
+++ b/llvm/docs/SourceLevelDebugging.rst
@@ -1006,13 +1006,13 @@ Given a class declaration with copy constructor declared as deleted:
foo(const foo&) = deleted;
};
-A C++ frontend would generate follwing:
+A C++ frontend would generate following:
.. code-block:: text
!17 = !DISubprogram(name: "foo", scope: !11, file: !1, line: 5, type: !18, scopeLine: 5, flags: DIFlagPublic | DIFlagPrototyped, spFlags: DISPFlagDeleted)
-and this will produce an additional DWARF attibute as:
+and this will produce an additional DWARF attribute as:
.. code-block:: text
@@ -2107,7 +2107,7 @@ The most straightforward way to use ``debugify`` is as follows::
This will inject synthetic DI to ``sample.ll`` run the ``pass-to-test``
and then check for missing DI.
-Some other ways to run debugify are avaliable:
+Some other ways to run debugify are available:
.. code-block:: bash
diff --git a/llvm/docs/TableGen/LangRef.rst b/llvm/docs/TableGen/LangRef.rst
index 74af1ee659f5..d7b869a9f8a8 100644
--- a/llvm/docs/TableGen/LangRef.rst
+++ b/llvm/docs/TableGen/LangRef.rst
@@ -142,7 +142,7 @@ values can be used in the class body.
A given class can only be defined once. A ``class`` declaration is
considered to define the class if any of the following is true:
-.. break ObjectBody into its consituents so that they are present here?
+.. break ObjectBody into its constituents so that they are present here?
#. The :token:`TemplateArgList` is present.
#. The :token:`Body` in the :token:`ObjectBody` is present and is not empty.
diff --git a/llvm/docs/TransformMetadata.rst b/llvm/docs/TransformMetadata.rst
index 68649424b717..817b41b43711 100644
--- a/llvm/docs/TransformMetadata.rst
+++ b/llvm/docs/TransformMetadata.rst
@@ -343,7 +343,7 @@ all of the aforementioned output loops.
It is recommended to add ``llvm.loop.disable_nonforced`` to
``llvm.loop.distribute.followup_fallback``. This avoids that the
-fallback version (which is likely never executed) is further optimzed
+fallback version (which is likely never executed) is further optimized
which would increase the code size.
Versioning LICM
diff --git a/llvm/docs/XRayFDRFormat.rst b/llvm/docs/XRayFDRFormat.rst
index 46f72c54228b..eb11a3c8fb88 100644
--- a/llvm/docs/XRayFDRFormat.rst
+++ b/llvm/docs/XRayFDRFormat.rst
@@ -28,7 +28,7 @@ Each trace file corresponds to a sequence of events in a particular thread.
The file has a header followed by a sequence of discriminated record types.
-The endianness of byte fields matches the endianess of the platform which
+The endianness of byte fields matches the endianness of the platform which
produced the trace file.
diff --git a/llvm/docs/YamlIO.rst b/llvm/docs/YamlIO.rst
index ac4f8d183220..561e06985c7a 100644
--- a/llvm/docs/YamlIO.rst
+++ b/llvm/docs/YamlIO.rst
@@ -730,7 +730,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
diff erent
+tag on a map. Using this functionality it is even possible to support
diff erent
mappings, as long as they are convertible.
To check a tag, inside your mapping() method you can use io.mapTag() to specify
diff --git a/llvm/docs/tutorial/BuildingAJIT1.rst b/llvm/docs/tutorial/BuildingAJIT1.rst
index 00ad94aa08ac..5c711fcba141 100644
--- a/llvm/docs/tutorial/BuildingAJIT1.rst
+++ b/llvm/docs/tutorial/BuildingAJIT1.rst
@@ -174,7 +174,7 @@ The ConcurrentIRCompiler utility will use the JITTargetMachineBuilder to build
llvm TargetMachines (which are not thread safe) as needed for compiles. After
this, we initialize our supporting members: ``DL``, ``Mangler`` and ``Ctx`` with
the input DataLayout, the ExecutionSession and DL member, and a new default
-constucted LLVMContext respectively. Now that our members have been initialized,
+constructed LLVMContext respectively. Now that our members have been initialized,
so the one thing that remains to do is to tweak the configuration of the
*JITDylib* that we will store our code in. We want to modify this dylib to
contain not only the symbols that we add to it, but also the symbols from our
@@ -204,7 +204,7 @@ REPL process as well. We do this by attaching a
Next we have a named constructor, ``Create``, which will build a KaleidoscopeJIT
instance that is configured to generate code for our host process. It does this
-by first generating a JITTargetMachineBuilder instance using that clases's
+by first generating a JITTargetMachineBuilder instance using that classes'
detectHost method and then using that instance to generate a datalayout for
the target process. Each of these operations can fail, so each returns its
result wrapped in an Expected value [3]_ that we must check for error before
@@ -320,4 +320,4 @@ Here is the code:
+-----------------------------+-----------------------------------------------+
.. [3] See the ErrorHandling section in the LLVM Programmer's Manual
- (http://llvm.org/docs/ProgrammersManual.html#error-handling)
\ No newline at end of file
+ (http://llvm.org/docs/ProgrammersManual.html#error-handling)
diff --git a/llvm/docs/tutorial/BuildingAJIT2.rst b/llvm/docs/tutorial/BuildingAJIT2.rst
index 1f818d945664..f1dc0aa7f4e9 100644
--- a/llvm/docs/tutorial/BuildingAJIT2.rst
+++ b/llvm/docs/tutorial/BuildingAJIT2.rst
@@ -170,7 +170,7 @@ can be implemented.
TransformFunction Transform;
};
- // From IRTransfomrLayer.cpp:
+ // From IRTransformLayer.cpp:
IRTransformLayer::IRTransformLayer(ExecutionSession &ES,
IRLayer &BaseLayer,
diff --git a/llvm/docs/tutorial/OCamlLangImpl3.rst b/llvm/docs/tutorial/OCamlLangImpl3.rst
index a76b46d1bf6b..fb0648928caa 100644
--- a/llvm/docs/tutorial/OCamlLangImpl3.rst
+++ b/llvm/docs/tutorial/OCamlLangImpl3.rst
@@ -59,7 +59,7 @@ parser, which will be used to report errors found during code generation
let double_type = double_type context
The static variables will be used during code generation.
-``Codgen.the_module`` is the LLVM construct that contains all of the
+``Codegen.the_module`` is the LLVM construct that contains all of the
functions and global variables in a chunk of code. In many ways, it is
the top-level structure that the LLVM IR uses to contain code.
@@ -78,7 +78,7 @@ function body.
With these basics in place, we can start talking about how to generate
code for each expression. Note that this assumes that the
-``Codgen.builder`` has been set up to generate code *into* something.
+``Codegen.builder`` has been set up to generate code *into* something.
For now, we'll assume that this has already been done, and we'll just
use it to emit code.
More information about the llvm-commits
mailing list