mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-11-22 02:33:06 +01:00
Correct 'teh' and other typos / repeated words.
Patch by Eitan Adler. Differential Revision: http://reviews.llvm.org/D8514 llvm-svn: 234939
This commit is contained in:
parent
5f4bd4ef8d
commit
b8c5d92511
@ -208,7 +208,7 @@ 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
|
||||
|
@ -3370,7 +3370,7 @@ 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
|
||||
@ -6577,7 +6577,7 @@ 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.
|
||||
|
||||
|
@ -940,7 +940,7 @@ 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
|
||||
@ -2651,7 +2651,7 @@ Important Derived Types
|
||||
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.
|
||||
|
@ -366,7 +366,7 @@ The decision to unroll the loop depends on the register pressure and the generat
|
||||
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.
|
||||
|
@ -332,7 +332,7 @@ as a field type:
|
||||
}
|
||||
};
|
||||
|
||||
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.
|
||||
@ -767,7 +767,7 @@ add "static const bool flow = true;". For instance:
|
||||
};
|
||||
|
||||
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 ]).
|
||||
|
||||
|
||||
|
@ -254,7 +254,7 @@ 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!
|
||||
|
@ -632,7 +632,7 @@ 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
|
||||
|
@ -61,7 +61,7 @@ char OptionKey<ValT, Base, Mem>::ID = 0;
|
||||
/// 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;
|
||||
|
@ -277,7 +277,7 @@ This will generate the following instruction sequence:
|
||||
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.
|
||||
|
||||
//===----------------------------------------------------------------------===//
|
||||
|
Loading…
Reference in New Issue
Block a user