diff options
Diffstat (limited to 'llvm/docs')
| -rw-r--r-- | llvm/docs/BitCodeFormat.rst | 4 | ||||
| -rw-r--r-- | llvm/docs/BranchWeightMetadata.rst | 6 | ||||
| -rw-r--r-- | llvm/docs/LangRef.rst | 10 | ||||
| -rw-r--r-- | llvm/docs/SourceLevelDebugging.rst | 2 | ||||
| -rw-r--r-- | llvm/docs/Statepoints.rst | 6 |
5 files changed, 14 insertions, 14 deletions
diff --git a/llvm/docs/BitCodeFormat.rst b/llvm/docs/BitCodeFormat.rst index 25ea421ed08..62d66f85d55 100644 --- a/llvm/docs/BitCodeFormat.rst +++ b/llvm/docs/BitCodeFormat.rst @@ -851,7 +851,7 @@ in the *paramattr* field of module block `FUNCTION`_ records, or within the *attr* field of function block ``INST_INVOKE`` and ``INST_CALL`` records. Entries within ``PARAMATTR_BLOCK`` are constructed to ensure that each is unique -(i.e., no two indicies represent equivalent attribute lists). +(i.e., no two indices represent equivalent attribute lists). .. _PARAMATTR_CODE_ENTRY: @@ -904,7 +904,7 @@ table entry, which may be referenced by 0-based index from instructions, constants, metadata, type symbol table entries, or other type operator records. Entries within ``TYPE_BLOCK`` are constructed to ensure that each entry is -unique (i.e., no two indicies represent structurally equivalent types). +unique (i.e., no two indices represent structurally equivalent types). .. _TYPE_CODE_NUMENTRY: .. _NUMENTRY: diff --git a/llvm/docs/BranchWeightMetadata.rst b/llvm/docs/BranchWeightMetadata.rst index 2ebc6c32416..6cbcb0f0fb2 100644 --- a/llvm/docs/BranchWeightMetadata.rst +++ b/llvm/docs/BranchWeightMetadata.rst @@ -27,7 +27,7 @@ Supported Instructions ^^^^^^^^^^^^^^ Metadata is only assigned to the conditional branches. There are two extra -operarands for the true and the false branch. +operands for the true and the false branch. .. code-block:: llvm @@ -114,12 +114,12 @@ CFG Modifications Branch Weight Metatada is not proof against CFG changes. If terminator operands' are changed some action should be taken. In other case some misoptimizations may -occur due to incorrent branch prediction information. +occur due to incorrect branch prediction information. Function Entry Counts ===================== -To allow comparing different functions durint inter-procedural analysis and +To allow comparing different functions during inter-procedural analysis and optimization, ``MD_prof`` nodes can also be assigned to a function definition. The first operand is a string indicating the name of the associated counter. diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst index 5e63daca706..7be5442cc7e 100644 --- a/llvm/docs/LangRef.rst +++ b/llvm/docs/LangRef.rst @@ -3875,7 +3875,7 @@ DILexicalBlock """""""""""""" ``DILexicalBlock`` nodes describe nested blocks within a :ref:`subprogram -<DISubprogram>`. The line number and column numbers are used to dinstinguish +<DISubprogram>`. The line number and column numbers are used to distinguish two lexical blocks at same depth. They are valid targets for ``scope:`` fields. @@ -4060,13 +4060,13 @@ 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 +string then it can be combined across functions and translation units. A self-reference can be used to create globally unique domain names. A descriptive string may optionally be provided as a second list entry. The metadata identifying each scope is also itself a list containing two or three entries. The first entry is the name of the scope. Note that if the name -is a string then it can be combined accross functions and translation units. A +is a string then it can be combined across functions and translation units. A self-reference can be used to create globally unique scope names. A metadata reference to the scope's domain is the second entry. A descriptive string may optionally be provided as a third list entry. @@ -5161,7 +5161,7 @@ is a catch block --- one where a personality routine attempts to transfer control to catch an exception. The ``args`` correspond to whatever information the personality routine requires to know if this is an appropriate place to catch the -exception. Control is tranfered to the ``exception`` label if the +exception. Control is transfered to the ``exception`` label if the ``catchpad`` is not an appropriate handler for the in-flight exception. The ``normal`` label should contain the code found in the ``catch`` portion of a ``try``/``catch`` sequence. The ``resultval`` has the type @@ -11311,7 +11311,7 @@ The first operand is a vector value to be written to memory. The second operand Semantics: """""""""" -The '``llvm.masked.scatter``' intrinsics is designed for writing selected vector elements to arbitrary memory addresses in a single IR operation. The operation may be conditional, when not all bits in the mask are switched on. It is useful for targets that support vector masked scatter and allows vectorizing basic blocks with data and control divergency. Other targets may support this intrinsic differently, for example by lowering it into a sequence of branches that guard scalar store operations. +The '``llvm.masked.scatter``' intrinsics is designed for writing selected vector elements to arbitrary memory addresses in a single IR operation. The operation may be conditional, when not all bits in the mask are switched on. It is useful for targets that support vector masked scatter and allows vectorizing basic blocks with data and control divergence. Other targets may support this intrinsic differently, for example by lowering it into a sequence of branches that guard scalar store operations. :: diff --git a/llvm/docs/SourceLevelDebugging.rst b/llvm/docs/SourceLevelDebugging.rst index d1f86279852..ad98abdc7b9 100644 --- a/llvm/docs/SourceLevelDebugging.rst +++ b/llvm/docs/SourceLevelDebugging.rst @@ -708,7 +708,7 @@ qualified name. Debugger users tend not to enter their search strings as "``a::b::c``". So the name entered in the name table must be demangled in order to chop it up appropriately and additional names must be manually entered into the table to make it effective as a name lookup table for debuggers to -se. +use. All debuggers currently ignore the "``.debug_pubnames``" table as a result of its inconsistent and useless public-only name content making it a waste of diff --git a/llvm/docs/Statepoints.rst b/llvm/docs/Statepoints.rst index d6a4b9c5fe2..26c597ce360 100644 --- a/llvm/docs/Statepoints.rst +++ b/llvm/docs/Statepoints.rst @@ -53,7 +53,7 @@ load barriers, store barriers, and safepoints. loads, merely loads of a particular type (in the original source language), or none at all. -#. Analogously, a store barrier is a code fragement that runs +#. Analogously, a store barrier is a code fragment that runs immediately before the machine store instruction, but after the computation of the value stored. The most common use of a store barrier is to update a 'card table' in a generational garbage @@ -160,7 +160,7 @@ of the call, we use the ``gc.result`` intrinsic. To get the relocation of each pointer in turn, we use the ``gc.relocate`` intrinsic with the appropriate index. Note that both the ``gc.relocate`` and ``gc.result`` are tied to the statepoint. The combination forms a "statepoint relocation -sequence" and represents the entitety of a parseable call or 'statepoint'. +sequence" and represents the entirety of a parseable call or 'statepoint'. When lowered, this example would generate the following x86 assembly: @@ -271,7 +271,7 @@ statepoint. transitions based on the function symbols involved (e.g. a call from a function with GC strategy "foo" to a function with GC strategy "bar"), indirect calls that are also GC transitions must also be supported. This - requirement is the driving force behing the decision to require that GC + requirement is the driving force behind the decision to require that GC transitions are explicitly marked. Let's revisit the sample given above, this time treating the call to ``@foo`` |
