mirror of
https://github.com/c64scene-ar/llvm-6502.git
synced 2024-12-24 06:30:19 +00:00
Fix documentation typos
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197757 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
parent
54317ec64a
commit
baf8c08693
@ -256,7 +256,7 @@ E: sylvestre@debian.org
|
||||
W: http://sylvestre.ledru.info/
|
||||
W: http://llvm.org/apt/
|
||||
D: Debian and Ubuntu packaging
|
||||
D: Continous integration with jenkins
|
||||
D: Continuous integration with jenkins
|
||||
|
||||
N: Andrew Lenharth
|
||||
E: alenhar2@cs.uiuc.edu
|
||||
|
@ -12,7 +12,7 @@
|
||||
This interface provides an OCaml API for LLVM scalar transforms, the
|
||||
classes in the [LLVMScalarOpts] library. *)
|
||||
|
||||
(** See the [llvm::createConstantPropogationPass] function. *)
|
||||
(** See the [llvm::createConstantPropagationPass] function. *)
|
||||
external add_constant_propagation : [<Llvm.PassManager.any] Llvm.PassManager.t
|
||||
-> unit
|
||||
= "llvm_add_constant_propagation"
|
||||
|
@ -16,9 +16,9 @@ class TestDisassembler(TestBase):
|
||||
self.assertEqual(count, 3)
|
||||
self.assertEqual(s, '\tjcxz\t-127')
|
||||
|
||||
def test_nonexistant_triple(self):
|
||||
def test_nonexistent_triple(self):
|
||||
with self.assertRaisesRegexp(Exception, "Could not obtain disassembler for triple"):
|
||||
Disassembler("nonexistant-triple-raises")
|
||||
Disassembler("nonexistent-triple-raises")
|
||||
|
||||
def test_get_instructions(self):
|
||||
sequence = '\x67\xe3\x81\x01\xc7' # jcxz -127; addl %eax, %edi
|
||||
|
@ -152,7 +152,7 @@ endmacro(add_llvm_target)
|
||||
# Add external project that may want to be built as part of llvm such as Clang,
|
||||
# lld, and Polly. This adds two options. One for the source directory of the
|
||||
# project, which defaults to ${CMAKE_CURRENT_SOURCE_DIR}/${name}. Another to
|
||||
# enable or disable building it with everthing else.
|
||||
# enable or disable building it with everything else.
|
||||
# Additional parameter can be specified as the name of directory.
|
||||
macro(add_llvm_external_project name)
|
||||
set(add_llvm_external_dir "${ARGN}")
|
||||
@ -248,7 +248,7 @@ function(add_unittest test_suite test_name)
|
||||
endfunction()
|
||||
|
||||
# This function provides an automatic way to 'configure'-like generate a file
|
||||
# based on a set of common and custom variables, specifically targetting the
|
||||
# based on a set of common and custom variables, specifically targeting the
|
||||
# variables needed for the 'lit.site.cfg' files. This function bundles the
|
||||
# common variables that any Lit instance is likely to need, and custom
|
||||
# variables can be passed in.
|
||||
|
@ -315,7 +315,7 @@ the properties which are associated with that component.
|
||||
|
||||
``BuildTool`` components are like ``Tool`` components, except that the
|
||||
tool is supposed to be built for the platform where the build is running
|
||||
(instead of that platform being targetted). Build systems are expected
|
||||
(instead of that platform being targeted). Build systems are expected
|
||||
to handle the fact that required libraries may need to be built for
|
||||
multiple platforms in order to be able to link this tool.
|
||||
|
||||
|
@ -273,7 +273,7 @@ there is a separate version for each compute architecture.
|
||||
For a list of all math functions implemented in libdevice, see
|
||||
`libdevice Users Guide <http://docs.nvidia.com/cuda/libdevice-users-guide/index.html>`_.
|
||||
|
||||
To accomodate various math-related compiler flags that can affect code
|
||||
To accommodate various math-related compiler flags that can affect code
|
||||
generation of libdevice code, the library code depends on a special LLVM IR
|
||||
pass (``NVVMReflect``) to handle conditional compilation within LLVM IR. This
|
||||
pass looks for calls to the ``@__nvvm_reflect`` function and replaces them
|
||||
|
@ -601,7 +601,7 @@ the classes multiple times yourself, e.g. by writing:
|
||||
...
|
||||
|
||||
A ``defm`` can also be used inside a multiclass providing several levels of
|
||||
multiclass instanciations.
|
||||
multiclass instantiations.
|
||||
|
||||
.. code-block:: llvm
|
||||
|
||||
@ -727,7 +727,7 @@ opened, as in the case with the ``CALL*`` instructions above.
|
||||
|
||||
It's also possible to use "let" expressions inside multiclasses, providing more
|
||||
ways to factor out commonality from the records, specially if using several
|
||||
levels of multiclass instanciations. This also avoids the need of using "let"
|
||||
levels of multiclass instantiations. This also avoids the need of using "let"
|
||||
expressions within subsequent records inside a multiclass.
|
||||
|
||||
.. code-block:: llvm
|
||||
|
@ -641,7 +641,7 @@ The YAML syntax supports tags as a way to specify the type of a node before
|
||||
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 differnt
|
||||
tag on a map. Using this functionality it is even possbile to support different
|
||||
mappings, as long as they are convertable.
|
||||
|
||||
To check a tag, inside your mapping() method you can use io.mapTag() to specify
|
||||
|
@ -280,10 +280,10 @@ TYPEDEF_HIDES_STRUCT = NO
|
||||
# For small to medium size projects (<1000 input files) the default value is
|
||||
# probably good enough. For larger projects a too small cache size can cause
|
||||
# doxygen to be busy swapping symbols to and from disk most of the time
|
||||
# causing a significant performance penality.
|
||||
# causing a significant performance penalty.
|
||||
# If the system has enough physical memory increasing the cache will improve the
|
||||
# performance by keeping more symbols in memory. Note that the value works on
|
||||
# a logarithmic scale so increasing the size by one will rougly double the
|
||||
# a logarithmic scale so increasing the size by one will roughly double the
|
||||
# memory usage. The cache size is given by this formula:
|
||||
# 2^(16+SYMBOL_CACHE_SIZE). The valid range is 0..9, the default is 0,
|
||||
# corresponding to a cache size of 2^16 = 65536 symbols
|
||||
|
@ -123,7 +123,7 @@ flags.
|
||||
The instruction selector sometimes misses folding a load into a compare. The
|
||||
pattern is written as (cmp reg, (load p)). Because the compare isn't
|
||||
commutative, it is not matched with the load on both sides. The dag combiner
|
||||
should be made smart enough to cannonicalize the load into the RHS of a compare
|
||||
should be made smart enough to canonicalize the load into the RHS of a compare
|
||||
when it can invert the result of the compare for free.
|
||||
|
||||
//===---------------------------------------------------------------------===//
|
||||
|
Loading…
Reference in New Issue
Block a user