mirror of
https://github.com/RPCSX/llvm.git
synced 2024-11-23 11:49:50 +00:00
fix some typos in the doc
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292014 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
parent
d4a4367ac0
commit
1d6becb423
@ -204,7 +204,7 @@ SOPP Instruction Examples
|
||||
For full list of supported instructions, refer to "SOPP Instructions" in ISA Manual.
|
||||
|
||||
Unless otherwise mentioned, little verification is performed on the operands
|
||||
of SOPP Instrucitons, so it is up to the programmer to be familiar with the
|
||||
of SOPP Instructions, so it is up to the programmer to be familiar with the
|
||||
range or acceptable values.
|
||||
|
||||
Vector ALU Instruction Examples
|
||||
|
@ -21,7 +21,7 @@ to know how it works under the hood. A prior knowledge of how Clang's profile
|
||||
guided optimization works is useful, but not required.
|
||||
|
||||
We start by showing how to use LLVM and Clang for code coverage analysis,
|
||||
then we briefly desribe LLVM's code coverage mapping format and the
|
||||
then we briefly describe LLVM's code coverage mapping format and the
|
||||
way that Clang and LLVM's code coverage tool work with this format. After
|
||||
the basics are down, more advanced features of the coverage mapping format
|
||||
are discussed - such as the data structures, LLVM IR representation and
|
||||
|
@ -738,7 +738,7 @@ to your path, you can push committed changes upstream with `git llvm push`.
|
||||
While this is using SVN under the hood, it does not require any interaction from
|
||||
you with git-svn.
|
||||
After a few minutes, `git pull` should get back the changes as they were
|
||||
commited. Note that a current limitation is that `git` does not directly record
|
||||
committed. Note that a current limitation is that `git` does not directly record
|
||||
file rename, and thus it is propagated to SVN as a combination of delete-add
|
||||
instead of a file rename.
|
||||
|
||||
|
@ -864,7 +864,7 @@ completing the walk over the archive they could use the ``joinErrors`` utility:
|
||||
|
||||
The ``joinErrors`` routine builds a special error type called ``ErrorList``,
|
||||
which holds a list of user defined errors. The ``handleErrors`` routine
|
||||
recognizes this type and will attempt to handle each of the contained erorrs in
|
||||
recognizes this type and will attempt to handle each of the contained errors in
|
||||
order. If all contained errors can be handled, ``handleErrors`` will return
|
||||
``Error::success()``, otherwise ``handleErrors`` will concatenate the remaining
|
||||
errors and return the resulting ``ErrorList``.
|
||||
|
@ -30,7 +30,7 @@ This proposal relates only to moving the hosting of our source-code repository
|
||||
from SVN hosted on our own servers to Git hosted on GitHub. We are not proposing
|
||||
using GitHub's issue tracker, pull-requests, or code-review.
|
||||
|
||||
Contributers will continue to earn commit access on demand under the Developer
|
||||
Contributors will continue to earn commit access on demand under the Developer
|
||||
Policy, except that that a GitHub account will be required instead of SVN
|
||||
username/password-hash.
|
||||
|
||||
@ -433,7 +433,7 @@ Concerns
|
||||
* 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
|
||||
sub-project Git mirror addesses this, even without SVN access.
|
||||
sub-project Git mirror addresses this, even without SVN access.
|
||||
* Preservation of the existing read/write SVN-based workflows relies on the
|
||||
GitHub SVN bridge, which is an extra dependency. Maintaining this locks us
|
||||
into GitHub and could restrict future workflow changes.
|
||||
|
@ -313,7 +313,7 @@ default outputs a ``ModuleID``:
|
||||
ret i32 0
|
||||
}
|
||||
|
||||
``ModuleID`` can unexpetedly match against ``CHECK`` lines. For example:
|
||||
``ModuleID`` can unexpectedly match against ``CHECK`` lines. For example:
|
||||
|
||||
.. code-block:: llvm
|
||||
|
||||
|
@ -593,12 +593,12 @@ the order in the definition of ``IntRegs`` in the target description file.
|
||||
FPRegsClass FPRegsRegClass;
|
||||
IntRegsClass IntRegsRegClass;
|
||||
...
|
||||
// IntRegs Sub-register Classess...
|
||||
// IntRegs Sub-register Classes...
|
||||
static const TargetRegisterClass* const IntRegsSubRegClasses [] = {
|
||||
NULL
|
||||
};
|
||||
...
|
||||
// IntRegs Super-register Classess...
|
||||
// IntRegs Super-register Classes..
|
||||
static const TargetRegisterClass* const IntRegsSuperRegClasses [] = {
|
||||
NULL
|
||||
};
|
||||
|
@ -731,7 +731,7 @@ 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 different
|
||||
mappings, as long as they are convertable.
|
||||
mappings, as long as they are convertible.
|
||||
|
||||
To check a tag, inside your mapping() method you can use io.mapTag() to specify
|
||||
what the tag should be. This will also add that tag when writing yaml.
|
||||
|
Loading…
Reference in New Issue
Block a user