Fx typos in documentation
This commit is contained in:
@@ -7,5 +7,5 @@ Finds improper usages of `XCTAssertEqual` and `XCTAssertNotEqual` and replaces
|
||||
them with `XCTAssertEqualObjects` or `XCTAssertNotEqualObjects`.
|
||||
|
||||
This makes tests less fragile, as many improperly rely on pointer equality for
|
||||
strings that have equal values. This assumption is not guarantted by the
|
||||
strings that have equal values. This assumption is not guaranteed by the
|
||||
language.
|
||||
|
||||
@@ -5097,7 +5097,7 @@ the configuration (without a prefix: ``Auto``).
|
||||
AfterControlStatements: true
|
||||
AfterFunctionDefinitionName: true
|
||||
|
||||
* ``bool AfterControlStatements`` If ``true``, put space betwee control statement keywords
|
||||
* ``bool AfterControlStatements`` If ``true``, put space between control statement keywords
|
||||
(for/if/while...) and opening parentheses.
|
||||
|
||||
.. code-block:: c++
|
||||
|
||||
@@ -501,7 +501,7 @@ So we can use the ``continuation`` field to construct the asynchronous stack:
|
||||
# In the example, the continuation is the first field member of the promise_type.
|
||||
# So they have the same addresses.
|
||||
# If we want to generalize the scripts to other coroutine types, we need to be sure
|
||||
# the continuation field is the first memeber of promise_type.
|
||||
# the continuation field is the first member of promise_type.
|
||||
self.continuation_addr = self.promise_addr
|
||||
|
||||
def next_task_addr(self):
|
||||
|
||||
@@ -2410,7 +2410,7 @@ this always needs to be called to grow the table.
|
||||
It takes three arguments. The first argument is the WebAssembly table
|
||||
to grow. The second argument is the reference typed value to store in
|
||||
the new table entries (the initialization value), and the third argument
|
||||
is the amound to grow the table by. It returns the previous table size
|
||||
is the amount to grow the table by. It returns the previous table size
|
||||
or -1. It will return -1 if not enough space could be allocated.
|
||||
|
||||
.. code-block:: c++
|
||||
|
||||
@@ -333,7 +333,7 @@ Missing features or with limited support
|
||||
- IR generation for non-trivial global destructors is incomplete (See:
|
||||
`PR48047 <https://llvm.org/PR48047>`_).
|
||||
|
||||
- Support of `destrutors with non-default address spaces
|
||||
- Support of `destructors with non-default address spaces
|
||||
<https://www.khronos.org/opencl/assets/CXX_for_OpenCL.html#_construction_initialization_and_destruction>`_
|
||||
is incomplete (See: `D109609 <https://reviews.llvm.org/D109609>`_).
|
||||
|
||||
|
||||
@@ -173,7 +173,7 @@ Bug Fixes to C++ Support
|
||||
a Unicode character whose name contains a ``-``.
|
||||
(Fixes `#64161 <https://github.com/llvm/llvm-project/issues/64161>`_)
|
||||
|
||||
- Fix cases where we ignore ambiguous name lookup when looking up memebers.
|
||||
- Fix cases where we ignore ambiguous name lookup when looking up members.
|
||||
(`#22413 <https://github.com/llvm/llvm-project/issues/22413>`_),
|
||||
(`#29942 <https://github.com/llvm/llvm-project/issues/29942>`_),
|
||||
(`#35574 <https://github.com/llvm/llvm-project/issues/35574>`_) and
|
||||
|
||||
@@ -11,7 +11,7 @@ Bringup on a New OS or Architecture
|
||||
CI builders
|
||||
===========
|
||||
|
||||
If you are contributing a port for a operating system or architecture which
|
||||
If you are contributing a port for an operating system or architecture which
|
||||
is not covered by existing CI builders, you will also have to present a plan
|
||||
for testing and contribute a CI builder. See
|
||||
`this guide <https://llvm.org/docs/HowToAddABuilder.html>`_ for information
|
||||
|
||||
@@ -153,7 +153,7 @@ We should also consider the opposite problem of having a ``file_time_type``
|
||||
that is able to represent a larger range than ``timespec``. At least in
|
||||
this case ``last_write_time`` can be used to get and set all possible values
|
||||
supported by the underlying filesystem; meaning ``last_write_time(p)`` will
|
||||
never throw a overflow error when retrieving a value.
|
||||
never throw an overflow error when retrieving a value.
|
||||
|
||||
However, this introduces a new problem, where users are allowed to attempt to
|
||||
create a time point beyond what the filesystem can represent. Two particular
|
||||
|
||||
@@ -21,7 +21,7 @@ Concepts
|
||||
**Pass:** A transformation applied to a *layer* that generates a new *layer* that is a more summarized, consolidated representation of the trace data.
|
||||
A pass merges instructions/blocks based on its specific purpose - for example, a pass designed to summarize a processor trace by function calls would merge all the blocks of a function into a single block representing the entire function.
|
||||
|
||||
The image below illusrates the transformation of a trace's representation (HTR)
|
||||
The image below illustrates the transformation of a trace's representation (HTR)
|
||||
|
||||
.. image:: media/htr-example.png
|
||||
|
||||
|
||||
@@ -115,7 +115,7 @@ Memory reclaiming
|
||||
Primary and Secondary allocators have different behaviors with regard to
|
||||
reclaiming. While Secondary mapped allocations can be unmapped on deallocation,
|
||||
it isn't the case for the Primary, which could lead to a steady growth of the
|
||||
RSS of a process. To counteracty this, if the underlying OS allows it, pages
|
||||
RSS of a process. To counteract this, if the underlying OS allows it, pages
|
||||
that are covered by contiguous free memory blocks in the Primary can be
|
||||
released: this generally means they won't count towards the RSS of a process and
|
||||
be zero filled on subsequent accesses). This is done in the deallocation path,
|
||||
|
||||
@@ -66,7 +66,7 @@ Offloading Specific Command-Line Arguments
|
||||
| It is also possible to specify :ref:`fopenmp-targets` without specifying
|
||||
``--offload-arch``. In that case, the executables ``amdgpu-arch`` or
|
||||
``nvptx-arch`` will be executed as part of the compiler driver to
|
||||
detect the device arhitecture automatically.
|
||||
detect the device architecture automatically.
|
||||
| Finally, the device architecture will also be automatically inferred with
|
||||
``--offload-arch=native``.
|
||||
|
||||
|
||||
@@ -1130,7 +1130,7 @@ LIBOMPTARGET_MIN_THREADS_FOR_LOW_TRIP_COUNT
|
||||
This environment variable defines a lower bound for the number of threads if a
|
||||
combined kernel, e.g., `target teams distribute parallel for`, has insufficient
|
||||
parallelism. Especially if the trip count of the loops is lower than the number
|
||||
of threads possible times the number of teams (aka. blocks) the device preferes
|
||||
of threads possible times the number of teams (aka. blocks) the device prefers
|
||||
(see also :ref:`LIBOMPTARGET_AMDGPU_TEAMS_PER_CU`), we will reduce the thread
|
||||
count to increase outer (team/block) parallelism. The thread count will never
|
||||
be reduced below the value passed for this environment variable though.
|
||||
|
||||
Reference in New Issue
Block a user