From: Kazu Hirata Date: Sat, 27 Feb 2021 18:09:23 +0000 (-0800) Subject: [llvm] Fix typos in documentation (NFC) X-Git-Tag: llvmorg-14-init~13854 X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=e8fa9014cce41e1057e295b035dda73420612686;p=platform%2Fupstream%2Fllvm.git [llvm] Fix typos in documentation (NFC) --- diff --git a/llvm/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst b/llvm/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst index 9ac9ea0..0d57674 100644 --- a/llvm/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst +++ b/llvm/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst @@ -500,7 +500,7 @@ If a DWARF expression is ill-formed, then the result is undefined. The following sections detail the rules for when a DWARF expression is ill-formed or results in an evaluation error. -A DWARF expression can either be encoded as a operation expression (see +A DWARF expression can either be encoded as an operation expression (see :ref:`amdgpu-dwarf-operation-expressions`), or as a location list expression (see :ref:`amdgpu-dwarf-location-list-expressions`). diff --git a/llvm/docs/AMDGPUModifierSyntax.rst b/llvm/docs/AMDGPUModifierSyntax.rst index 7851a3e..d6a3879 100644 --- a/llvm/docs/AMDGPUModifierSyntax.rst +++ b/llvm/docs/AMDGPUModifierSyntax.rst @@ -422,7 +422,7 @@ GFX7, GFX8 and GFX10 only. r128 Specifies 128 bits texture resource size. =================== ================================================ -.. WARNING:: Using this modifier should descrease *rsrc* operand size from 8 to 4 dwords, but assembler does not currently support this feature. +.. WARNING:: Using this modifier should decrease *rsrc* operand size from 8 to 4 dwords, but assembler does not currently support this feature. tfe ~~~ @@ -831,7 +831,7 @@ GFX10 only. Unified format is a replacement for :ref:`data` and :ref:`numeric` formats. For compatibility with older ISA, -:ref:`syntax with data and numeric formats` is still accepthed +:ref:`syntax with data and numeric formats` is still accepted provided that the combination of formats can be mapped to a unified format. Supported unified formats and equivalent combinations of data and numeric formats diff --git a/llvm/docs/AMDGPUUsage.rst b/llvm/docs/AMDGPUUsage.rst index b496c30..5177cce 100644 --- a/llvm/docs/AMDGPUUsage.rst +++ b/llvm/docs/AMDGPUUsage.rst @@ -528,7 +528,7 @@ AMDGPU supports target IDs. See `Clang Offload Bundler description. The AMDGPU target specific information is: **processor** - Is a AMDGPU processor or alternative processor name specified in + Is an AMDGPU processor or alternative processor name specified in :ref:`amdgpu-processor-table`. The non-canonical form target ID allows both the primary processor and alternative processor names. The canonical form target ID only allow the primary processor name. @@ -4580,7 +4580,7 @@ There are different methods used for initializing flat scratch: Private Segment Buffer ++++++++++++++++++++++ -Private Segment Buffer SGPR register is used to initilize 4 SGPRs +Private Segment Buffer SGPR register is used to initialize 4 SGPRs that are used as a V# to access scratch. CP uses the value provided by the runtime. It is used, together with Scratch Wavefront Offset as an offset, to access the private memory space using a segment address. See @@ -6042,7 +6042,7 @@ For GFX90A: wavefront. * No special action is required for coherence between wavefronts in the same - work-group since they exeute on the same CU. The exception is when in + work-group since they execute on the same CU. The exception is when in tgsplit execution mode as wavefronts of the same work-group can be in different CUs and so a ``buffer_wbinvl1_vol`` is required as described in the following item. diff --git a/llvm/docs/BitCodeFormat.rst b/llvm/docs/BitCodeFormat.rst index cf2c611..df0e195 100644 --- a/llvm/docs/BitCodeFormat.rst +++ b/llvm/docs/BitCodeFormat.rst @@ -264,7 +264,7 @@ Abbreviated Record Encoding ``[, fields...]`` -An abbreviated record is a abbreviation id followed by a set of fields that are +An abbreviated record is an abbreviation id followed by a set of fields that are encoded according to the `abbreviation definition`_. This allows records to be encoded significantly more densely than records encoded with the `UNABBREV_RECORD`_ type, and allows the abbreviation types to be specified in diff --git a/llvm/docs/CommandGuide/llvm-install-name-tool.rst b/llvm/docs/CommandGuide/llvm-install-name-tool.rst index 33eb998..9309215 100644 --- a/llvm/docs/CommandGuide/llvm-install-name-tool.rst +++ b/llvm/docs/CommandGuide/llvm-install-name-tool.rst @@ -35,7 +35,7 @@ the same `` value. Change an install name ```` to ```` in the specified binary. Can be specified multiple times to change multiple dependent shared library install names. Option is ignored if ```` is not listed - in the specfied binary. + in the specified binary. .. option:: -delete_rpath @@ -54,7 +54,7 @@ the same `` value. .. option:: -id Change shared library's identification name under LC_ID_DYLIB to ```` in the - specfied binary. If specified multiple times, only the last :option:`-id` option is + specified binary. If specified multiple times, only the last :option:`-id` option is selected. Option is ignored if the specified Mach-O binary is not a dynamic shared library. .. option:: -rpath diff --git a/llvm/docs/CommandGuide/tblgen.rst b/llvm/docs/CommandGuide/tblgen.rst index 53064964..042d649 100644 --- a/llvm/docs/CommandGuide/tblgen.rst +++ b/llvm/docs/CommandGuide/tblgen.rst @@ -126,7 +126,7 @@ llvm-tblgen Options .. option:: -gen-attrs - Geneerate attributes. + Generate attributes. .. option:: -gen-automata @@ -218,7 +218,7 @@ llvm-tblgen Options .. option:: -gicombiner-show-expansions - Make -gen-global-isel-combiner use C++ comments to indicate occurences + Make -gen-global-isel-combiner use C++ comments to indicate occurrences of code expansion. .. option:: -gicombiner-stop-after-build diff --git a/llvm/docs/CommandLine.rst b/llvm/docs/CommandLine.rst index c67e733..e549d49 100644 --- a/llvm/docs/CommandLine.rst +++ b/llvm/docs/CommandLine.rst @@ -387,7 +387,7 @@ now is: -quiet - Don't print informational messages In this case, it is sort of awkward that flag names correspond directly to enum -names, because we probably don't want a enum definition named "``g``" in our +names, because we probably don't want an enum definition named "``g``" in our program. Because of this, we can alternatively write this example like this: .. code-block:: c++ diff --git a/llvm/docs/Coroutines.rst b/llvm/docs/Coroutines.rst index 268e9c7..72ef3f8 100644 --- a/llvm/docs/Coroutines.rst +++ b/llvm/docs/Coroutines.rst @@ -190,7 +190,7 @@ coroutine. Therefore an async coroutine returns `void`. define swiftcc void @async_coroutine(i8* %async.ctxt, i8*, i8*) { } -Values live accross a suspend point need to be stored in the coroutine frame to +Values live across a suspend point need to be stored in the coroutine frame to be available in the continuation function. This frame is stored as a tail to the `async context`. @@ -1206,7 +1206,7 @@ The third argument is the `async context` argument in the current coroutine. The fourth argument is the address of the `async function pointer` struct. Lowering will update the context size requirement in this struct by adding the coroutine frame size requirement to the initial size requirement as specified by -the first argument of this intrinisc. +the first argument of this intrinsic. Semantics: @@ -1572,7 +1572,7 @@ The second argument is the `context projection function`. It should describe how-to restore the `async context` in the continuation function from the first argument of the continuation function. Its type is `i8* (i8*)`. -The third argument is the function that models tranfer to the callee at the +The third argument is the function that models transfer to the callee at the suspend point. It should take 3 arguments. Lowering will `musttail` call this function. diff --git a/llvm/docs/Frontend/PerformanceTips.rst b/llvm/docs/Frontend/PerformanceTips.rst index f9e23fd..5889329 100644 --- a/llvm/docs/Frontend/PerformanceTips.rst +++ b/llvm/docs/Frontend/PerformanceTips.rst @@ -81,7 +81,7 @@ Prefer zext over sext when legal On some architectures (X86_64 is one), sign extension can involve an extra instruction whereas zero extension can be folded into a load. LLVM will try to replace a sext with a zext when it can be proven safe, but if you have -information in your source language about the range of a integer value, it can +information in your source language about the range of an integer value, it can be profitable to use a zext rather than a sext. Alternatively, you can :ref:`specify the range of the value using metadata diff --git a/llvm/docs/JITLink.rst b/llvm/docs/JITLink.rst index e194718..3b808ce 100644 --- a/llvm/docs/JITLink.rst +++ b/llvm/docs/JITLink.rst @@ -16,7 +16,7 @@ accessible. If it is not, please submit a patch (:doc:`Contributing`) or file a bug (:doc:`HowToSubmitABug`). JITLink is a library for :ref:`jit_linking`. It was built to support the ORC JIT -APIs and is most commonly accesed via ORC's ObjectLinkingLayer API. JITLink was +APIs and is most commonly accessed via ORC's ObjectLinkingLayer API. JITLink was developed with the aim of supporting the full set of features provided by each object format; including static initializers, exception handling, thread local variables, and language runtime registration. Supporting these features enables @@ -520,7 +520,7 @@ certain points by the introduction of JITLink :ref:`passes`: working memory and fixed up. Passes run at this stage can make late optimizations to the graph and content based on address layout. - Notable use cases: GOT and PLT relaxation, where GOT and PLT acceses are + Notable use cases: GOT and PLT relaxation, where GOT and PLT accesses are bypassed for fixup targets that are directly accessible under the assigned memory layout. @@ -787,7 +787,7 @@ for them by an ``ObjectLinkingLayer`` instance, but they can be created manually ``ObjectLinkingLayer`` usually creates ``LinkGraphs``. #. ``createLinkGraph__`` can be used when - both the object format and achitecture are known ahead of time. + both the object format and architecture are known ahead of time. #. ``createLinkGraph_`` can be used when the object format is known ahead of time, but the architecture is not. In this case the @@ -894,7 +894,7 @@ main function using the -args option: printf("arg %i is \"%s\"\n", i, argv[i]); } - % cat pring-args-main.c + % cat print-args-main.c void print_args(int argc, char *argv[]); int main(int argc, char *argv[]) { @@ -1093,7 +1093,7 @@ Major outstanding projects include: JITLink Availability and Feature Status --------------------------------------- -.. list-table:: Avalability and Status +.. list-table:: Availability and Status :widths: 10 30 30 30 :header-rows: 1 diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst index 46eab12..76a7514 100644 --- a/llvm/docs/LangRef.rst +++ b/llvm/docs/LangRef.rst @@ -4329,7 +4329,7 @@ ARM and ARM's Thumb2 mode: - ``L``: An immediate integer whose negation is valid for a data-processing instruction. (Can be used with template modifier "``n``" to print the negated value). -- ``M``: A power of two or a integer between 0 and 32. +- ``M``: A power of two or an integer between 0 and 32. - ``N``: Invalid immediate constraint. - ``O``: Invalid immediate constraint. - ``r``: A general-purpose 32-bit integer register (``r0-r15``). @@ -4723,7 +4723,7 @@ debug information. There are two metadata primitives: strings and nodes. Metadata does not have a type, and is not a value. If referenced from a ``call`` instruction, it uses the ``metadata`` type. -All metadata are identified in syntax by a exclamation point ('``!``'). +All metadata are identified in syntax by an exclamation point ('``!``'). .. _metadata-string: @@ -12000,7 +12000,7 @@ arrays in C99. Semantics: """""""""" -This intrinsic returns a opaque pointer value that can be passed to +This intrinsic returns an opaque pointer value that can be passed to :ref:`llvm.stackrestore `. When an ``llvm.stackrestore`` intrinsic is executed with a value saved from ``llvm.stacksave``, it effectively restores the state of the stack to @@ -12053,7 +12053,7 @@ Overview: The '``llvm.get.dynamic.area.offset.*``' intrinsic family is used to get the offset from native stack pointer to the address of the most recent dynamic alloca on the caller's stack. These intrinsics are - intendend for use in combination with + intended for use in combination with :ref:`llvm.stacksave ` to get a pointer to the most recent dynamic alloca. This is useful, for example, for AddressSanitizer's stack unpoisoning routines. @@ -12170,7 +12170,7 @@ Semantics: """""""""" When directly supported, reading the cycle counter should not modify any -memory. Implementations are allowed to either return a application +memory. Implementations are allowed to either return an application specific value or a system wide value. On backends without support, this is lowered to a constant 0. diff --git a/llvm/docs/Lexicon.rst b/llvm/docs/Lexicon.rst index 0309082..761aa4b 100644 --- a/llvm/docs/Lexicon.rst +++ b/llvm/docs/Lexicon.rst @@ -98,7 +98,7 @@ E **ento** This namespace houses the `Clang Static Analyzer `_. - It is an abbreviaton of `entomology `_. + It is an abbreviation of `entomology `_. *"Entomology is the scientific study of insects."* diff --git a/llvm/docs/MIRLangRef.rst b/llvm/docs/MIRLangRef.rst index ba6bdcb..6398fd7f 100644 --- a/llvm/docs/MIRLangRef.rst +++ b/llvm/docs/MIRLangRef.rst @@ -834,7 +834,7 @@ represented by an empty ``DebugLoc`` object in the machine instruction. Fixed variable locations ^^^^^^^^^^^^^^^^^^^^^^^^ -There are several ways of specifying variable locations. The simpliest is +There are several ways of specifying variable locations. The simplest is describing a variable that is permanently located on the stack. In the stack or fixedStack attribute of the machine function, the variable, scope, and any qualifying location modifier are provided: diff --git a/llvm/docs/MemorySSA.rst b/llvm/docs/MemorySSA.rst index 224b57d..b5c2bad 100644 --- a/llvm/docs/MemorySSA.rst +++ b/llvm/docs/MemorySSA.rst @@ -176,7 +176,7 @@ Going from the top down: this block could either be ``2`` or ``3``. - ``MemoryUse(5)`` notes that ``load i8, i8* %p1`` is a use of memory, and that it's clobbered by ``5``. -- ``4 = MemoryDef(5)`` notes that ``store i8 2, i8* %p2`` is a definition; it's +- ``4 = MemoryDef(5)`` notes that ``store i8 2, i8* %p2`` is a definition; its reaching definition is ``5``. - ``MemoryUse(1)`` notes that ``load i8, i8* %p3`` is just a user of memory, and the last thing that could clobber this use is above ``while.cond`` (e.g. @@ -233,7 +233,7 @@ queries ``GlobalsAA``, one that always stops at ``MemoryPhi`` nodes, etc). Default walker APIs ^^^^^^^^^^^^^^^^^^^ -There are two main APIs used to retrive the clobbering access using the walker: +There are two main APIs used to retrieve the clobbering access using the walker: - ``MemoryAccess *getClobberingMemoryAccess(MemoryAccess *MA);`` return the clobbering memory access for ``MA``, caching all intermediate results diff --git a/llvm/docs/MergeFunctions.rst b/llvm/docs/MergeFunctions.rst index 1329412..02344bc 100644 --- a/llvm/docs/MergeFunctions.rst +++ b/llvm/docs/MergeFunctions.rst @@ -134,7 +134,7 @@ How it could this be done? Just convert each function to a number, and gather all of them in a special hash-table. Functions with equal hashes are equal. Good hashing means, that every function part must be taken into account. That means we have to convert every function part into some number, and then add it -into the hash. The lookup-up time would be small, but such a approach adds some +into the hash. The lookup-up time would be small, but such an approach adds some delay due to the hashing routine. Logarithmical search diff --git a/llvm/docs/ORCv2.rst b/llvm/docs/ORCv2.rst index 06f743d..4c3974b 100644 --- a/llvm/docs/ORCv2.rst +++ b/llvm/docs/ORCv2.rst @@ -829,7 +829,7 @@ Further Future Work *speculative* JIT compilation: compilation of code that is not needed yet, but which we have reason to believe will be needed in the future. This can be used to hide compile latency and improve JIT throughput. A proof-of-concept - exmaple of speculative compilation with ORC has already been developed (see + example of speculative compilation with ORC has already been developed (see ``llvm/examples/SpeculativeJIT``). Future work on this is likely to focus on re-using and improving existing profiling support (currently used by PGO) to feed speculation decisions, as well as built-in tools to simplify use of diff --git a/llvm/docs/Passes.rst b/llvm/docs/Passes.rst index d146ce7..869408f 100644 --- a/llvm/docs/Passes.rst +++ b/llvm/docs/Passes.rst @@ -336,7 +336,7 @@ graph at only two spots. Furthermore, a hierarchical region tree is built. ``-scalar-evolution``: Scalar Evolution Analysis ------------------------------------------------ -The ``ScalarEvolution`` analysis can be used to analyze and catagorize scalar +The ``ScalarEvolution`` analysis can be used to analyze and categorize scalar expressions in loops. It specializes in recognizing general induction variables, representing them with the abstract and opaque ``SCEV`` class. Given this analysis, trip counts of loops and other important properties can be @@ -1114,7 +1114,7 @@ algorithm: return returns something else (like constant 0), and can still be TRE'd. It can be TRE'd if *all other* return instructions in the function return the exact same value. -#. If it can prove that callees do not access theier caller stack frame, they +#. If it can prove that callees do not access their caller stack frame, they are marked as eligible for tail call elimination (by the code generator). Utility Passes diff --git a/llvm/docs/ProgrammersManual.rst b/llvm/docs/ProgrammersManual.rst index 7713a35..c10629d 100644 --- a/llvm/docs/ProgrammersManual.rst +++ b/llvm/docs/ProgrammersManual.rst @@ -2468,7 +2468,7 @@ Basic Inspection and Traversal Routines The LLVM compiler infrastructure have many different data structures that may be traversed. Following the example of the C++ standard template library, the techniques used to traverse these various data structures are all basically the -same. For a enumerable sequence of values, the ``XXXbegin()`` function (or +same. For an enumerable sequence of values, the ``XXXbegin()`` function (or method) returns an iterator to the start of the sequence, the ``XXXend()`` function returns an iterator pointing to one past the last valid element of the sequence, and there is some ``XXXiterator`` data type that is common between the diff --git a/llvm/docs/StackMaps.rst b/llvm/docs/StackMaps.rst index 7c9cead..1501ddd 100644 --- a/llvm/docs/StackMaps.rst +++ b/llvm/docs/StackMaps.rst @@ -24,7 +24,7 @@ containing the stack map. LLVM emits stack map data into the object code within a designated :ref:`stackmap-section`. This stack map data contains a record for each stack map. The record stores the stack map's instruction address -and contains a entry for each mapped value. Each entry encodes a +and contains an entry for each mapped value. Each entry encodes a value's location as a register, stack offset, or constant. A patch point is an instruction address at which space is reserved for diff --git a/llvm/docs/Statepoints.rst b/llvm/docs/Statepoints.rst index 7a43372..8141e2e 100644 --- a/llvm/docs/Statepoints.rst +++ b/llvm/docs/Statepoints.rst @@ -393,7 +393,7 @@ to unmanaged code. The resulting relocation sequence is: ret i8 addrspace(1)* %obj.relocated } -During lowering, this will result in a instruction selection DAG that looks +During lowering, this will result in an instruction selection DAG that looks something like: :: @@ -703,7 +703,7 @@ Safepoint Semantics & Verification The fundamental correctness property for the compiled code's correctness w.r.t. the garbage collector is a dynamic one. It must be -the case that there is no dynamic trace such that a operation +the case that there is no dynamic trace such that an operation involving a potentially relocated pointer is observably-after a safepoint which could relocate it. 'observably-after' is this usage means that an outside observer could observe this sequence of events diff --git a/llvm/docs/TableGen/ProgRef.rst b/llvm/docs/TableGen/ProgRef.rst index f5a7760..c60bffe 100644 --- a/llvm/docs/TableGen/ProgRef.rst +++ b/llvm/docs/TableGen/ProgRef.rst @@ -509,7 +509,7 @@ primary value. Here are the possible suffixes for some primary *value*. The paste operator ------------------ -The paste operator (``#``) is the only infix operator availabe in TableGen +The paste operator (``#``) is the only infix operator available in TableGen expressions. It allows you to concatenate strings or lists, but has a few unusual features. diff --git a/llvm/docs/XRay.rst b/llvm/docs/XRay.rst index 72768fa..969f7ee 100644 --- a/llvm/docs/XRay.rst +++ b/llvm/docs/XRay.rst @@ -316,7 +316,7 @@ Minimizing Binary Size XRay supports several different instrumentation points including ``function-entry``, ``function-exit``, ``custom``, and ``typed`` points. These can be enabled individually -using the ``-fxray-instrumentaton-bundle=`` flag. For example if you only wanted to +using the ``-fxray-instrumentation-bundle=`` flag. For example if you only wanted to instrument function entry and custom points you could specify: :: diff --git a/llvm/docs/YamlIO.rst b/llvm/docs/YamlIO.rst index 9dbb2b2..68bc0e4 100644 --- a/llvm/docs/YamlIO.rst +++ b/llvm/docs/YamlIO.rst @@ -288,7 +288,7 @@ ScalarEnumerationTraits ----------------------- YAML I/O supports translating between in-memory enumerations and a set of string values in YAML documents. This is done by specializing ScalarEnumerationTraits<> -on your enumeration type and define a enumeration() method. +on your enumeration type and define an enumeration() method. For instance, suppose you had an enumeration of CPUs and a struct with it as a field: @@ -391,7 +391,7 @@ on MyFlags and provide the bit values and their names. With the above, YAML I/O (when writing) will test mask each value in the bitset trait against the flags field, and each that matches will cause the corresponding string to be added to the flow sequence. The opposite -is done when reading and any unknown string values will result in a error. With +is done when reading and any unknown string values will result in an error. With the above schema, a same valid YAML document is: .. code-block:: yaml @@ -439,7 +439,7 @@ to the flow sequence. Custom Scalar ------------- Sometimes for readability a scalar needs to be formatted in a custom way. For -instance your internal data structure may use a integer for time (seconds since +instance your internal data structure may use an integer for time (seconds since some epoch), but in YAML it would be much nicer to express that integer in some time format (e.g. 4-May-2012 10:30pm). YAML I/O has a way to support custom formatting and parsing of scalar types by specializing ScalarTraits<> on diff --git a/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl10.rst b/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl10.rst index dd7d547..d575e0a 100644 --- a/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl10.rst +++ b/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl10.rst @@ -30,7 +30,7 @@ need not be a scary or mystical process! Now that you've seen some of the basics, I strongly encourage you to take the code and hack on it. For example, try adding: -- **global variables** - While global variables have questional value +- **global variables** - While global variables have questionable value in modern software engineering, they are often useful when putting together quick little hacks like the Kaleidoscope compiler itself. Fortunately, our current setup makes it very easy to add global