mirror of
https://github.com/RPCSX/llvm.git
synced 2024-11-27 05:30:49 +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.
|
For full list of supported instructions, refer to "SOPP Instructions" in ISA Manual.
|
||||||
|
|
||||||
Unless otherwise mentioned, little verification is performed on the operands
|
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.
|
range or acceptable values.
|
||||||
|
|
||||||
Vector ALU Instruction Examples
|
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.
|
guided optimization works is useful, but not required.
|
||||||
|
|
||||||
We start by showing how to use LLVM and Clang for code coverage analysis,
|
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
|
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
|
the basics are down, more advanced features of the coverage mapping format
|
||||||
are discussed - such as the data structures, LLVM IR representation and
|
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
|
While this is using SVN under the hood, it does not require any interaction from
|
||||||
you with git-svn.
|
you with git-svn.
|
||||||
After a few minutes, `git pull` should get back the changes as they were
|
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
|
file rename, and thus it is propagated to SVN as a combination of delete-add
|
||||||
instead of a file rename.
|
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``,
|
The ``joinErrors`` routine builds a special error type called ``ErrorList``,
|
||||||
which holds a list of user defined errors. The ``handleErrors`` routine
|
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
|
order. If all contained errors can be handled, ``handleErrors`` will return
|
||||||
``Error::success()``, otherwise ``handleErrors`` will concatenate the remaining
|
``Error::success()``, otherwise ``handleErrors`` will concatenate the remaining
|
||||||
errors and return the resulting ``ErrorList``.
|
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
|
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.
|
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
|
Policy, except that that a GitHub account will be required instead of SVN
|
||||||
username/password-hash.
|
username/password-hash.
|
||||||
|
|
||||||
@ -433,7 +433,7 @@ Concerns
|
|||||||
* Using the monolithic repository may add overhead for those *integrating* a
|
* 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
|
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
|
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
|
* Preservation of the existing read/write SVN-based workflows relies on the
|
||||||
GitHub SVN bridge, which is an extra dependency. Maintaining this locks us
|
GitHub SVN bridge, which is an extra dependency. Maintaining this locks us
|
||||||
into GitHub and could restrict future workflow changes.
|
into GitHub and could restrict future workflow changes.
|
||||||
|
@ -313,7 +313,7 @@ default outputs a ``ModuleID``:
|
|||||||
ret i32 0
|
ret i32 0
|
||||||
}
|
}
|
||||||
|
|
||||||
``ModuleID`` can unexpetedly match against ``CHECK`` lines. For example:
|
``ModuleID`` can unexpectedly match against ``CHECK`` lines. For example:
|
||||||
|
|
||||||
.. code-block:: llvm
|
.. code-block:: llvm
|
||||||
|
|
||||||
|
@ -593,12 +593,12 @@ the order in the definition of ``IntRegs`` in the target description file.
|
|||||||
FPRegsClass FPRegsRegClass;
|
FPRegsClass FPRegsRegClass;
|
||||||
IntRegsClass IntRegsRegClass;
|
IntRegsClass IntRegsRegClass;
|
||||||
...
|
...
|
||||||
// IntRegs Sub-register Classess...
|
// IntRegs Sub-register Classes...
|
||||||
static const TargetRegisterClass* const IntRegsSubRegClasses [] = {
|
static const TargetRegisterClass* const IntRegsSubRegClasses [] = {
|
||||||
NULL
|
NULL
|
||||||
};
|
};
|
||||||
...
|
...
|
||||||
// IntRegs Super-register Classess...
|
// IntRegs Super-register Classes..
|
||||||
static const TargetRegisterClass* const IntRegsSuperRegClasses [] = {
|
static const TargetRegisterClass* const IntRegsSuperRegClasses [] = {
|
||||||
NULL
|
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
|
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
|
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
|
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
|
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.
|
what the tag should be. This will also add that tag when writing yaml.
|
||||||
|
Loading…
Reference in New Issue
Block a user