Skip to content

[LangRef] Fix spelling mistakes #86013

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Mar 25, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
34 changes: 17 additions & 17 deletions llvm/docs/LangRef.rst
Original file line number Diff line number Diff line change
Expand Up @@ -2571,7 +2571,7 @@ are grouped into a single :ref:`attribute group <attrgrp>`.
``sanitize_memtag``
This attribute indicates that the global variable should have AArch64 memory
tags (MTE) instrumentation applied to it. This attribute causes the
suppression of certain optimisations, like GlobalMerge, as well as ensuring
suppression of certain optimizations, like GlobalMerge, as well as ensuring
extra directives are emitted in the assembly and extra bits of metadata are
placed in the object file so that the linker can ensure the accesses are
protected by MTE. This attribute is added by clang when
Expand Down Expand Up @@ -3638,7 +3638,7 @@ floating-point transformations.

``contract``
Allow floating-point contraction (e.g. fusing a multiply followed by an
addition into a fused multiply-and-add). This does not enable reassociating
addition into a fused multiply-and-add). This does not enable reassociation
to form arbitrary contractions. For example, ``(a*b) + (c*d) + e`` can not
be transformed into ``(a*b) + ((c*d) + e)`` to create two fma operations.

Expand Down Expand Up @@ -7365,7 +7365,7 @@ matches the ``llvm.loop.parallel_accesses`` list.
If all memory-accessing instructions in a loop have
``llvm.access.group`` metadata that each refer to one of the access
groups of a loop's ``llvm.loop.parallel_accesses`` metadata, then the
loop has no loop carried memory dependences and is considered to be a
loop has no loop carried memory dependencies and is considered to be a
parallel loop.

Note that if not all memory access instructions belong to an access
Expand Down Expand Up @@ -13577,12 +13577,12 @@ Overview:
"""""""""

The '``llvm.seh.try.begin``' and '``llvm.seh.try.end``' intrinsics mark
the boundary of a _try region for Windows SEH Asynchrous Exception Handling.
the boundary of a _try region for Windows SEH Asynchronous Exception Handling.

Semantics:
""""""""""

When a C-function is compiled with Windows SEH Asynchrous Exception option,
When a C-function is compiled with Windows SEH Asynchronous Exception option,
-feh_asynch (aka MSVC -EHa), these two intrinsics are injected to mark _try
boundary and to prevent potential exceptions from being moved across boundary.
Any set of operations can then be confined to the region by reading their leaf
Expand All @@ -13603,7 +13603,7 @@ Overview:
"""""""""

The '``llvm.seh.scope.begin``' and '``llvm.seh.scope.end``' intrinsics mark
the boundary of a CPP object lifetime for Windows SEH Asynchrous Exception
the boundary of a CPP object lifetime for Windows SEH Asynchronous Exception
Handling (MSVC option -EHa).

Semantics:
Expand Down Expand Up @@ -17713,7 +17713,7 @@ Examples
%res = call i4 @llvm.udiv.fix.sat.i4(i4 8, i4 2, i32 2) ; %res = 15 (2 / 0.5 = 4 => 3.75)


Specialised Arithmetic Intrinsics
Specialized Arithmetic Intrinsics
---------------------------------

.. _i_intr_llvm_canonicalize:
Expand Down Expand Up @@ -18037,9 +18037,9 @@ The '``llvm.loop.decrement.reg.*``' intrinsics do an integer ``SUB`` of its
two operands, which is not allowed to wrap. They return the remaining number of
iterations still to be executed, and can be used together with a ``PHI``,
``ICMP`` and ``BR`` to control the number of loop iterations executed. Any
optimisations are allowed to treat it is a ``SUB``, and it is supported by
optimizations are allowed to treat it is a ``SUB``, and it is supported by
SCEV, so it's the backends responsibility to handle cases where it may be
optimised. These intrinsics are marked as ``IntrNoDuplicate`` to avoid
optimized. These intrinsics are marked as ``IntrNoDuplicate`` to avoid
optimizers duplicating these instructions.


Expand Down Expand Up @@ -18741,7 +18741,7 @@ Arguments:
The first argument is the vector to be counted. This argument must be a vector
with integer element type. The return type must also be an integer type which is
wide enough to hold the maximum number of elements of the source vector. The
behaviour of this intrinsic is undefined if the return type is not wide enough
behavior of this intrinsic is undefined if the return type is not wide enough
for the number of elements in the input vector.

The second argument is a constant flag that indicates whether the intrinsic
Expand Down Expand Up @@ -22026,7 +22026,7 @@ and ``evl2`` are unsigned integers indicating the explicit vector lengths of
``vec1`` and ``vec2`` respectively. ``imm``, ``evl1`` and ``evl2`` should
respect the following constraints: ``-evl1 <= imm < evl1``, ``0 <= evl1 <= VL``
and ``0 <= evl2 <= VL``, where ``VL`` is the runtime vector factor. If these
constraints are not satisfied the intrinsic has undefined behaviour.
constraints are not satisfied the intrinsic has undefined behavior.

Semantics:
""""""""""
Expand Down Expand Up @@ -24442,7 +24442,7 @@ operand. The pointer alignment defaults to 1.
Semantics:
""""""""""

The '``llvm.masked.compressstore``' intrinsic is designed for compressing data in memory. It allows to collect elements from possibly non-adjacent lanes of a vector and store them contiguously in memory in one IR operation. It is useful for targets that support compressing store operations and allows vectorizing loops with cross-iteration dependences like in the following example:
The '``llvm.masked.compressstore``' intrinsic is designed for compressing data in memory. It allows to collect elements from possibly non-adjacent lanes of a vector and store them contiguously in memory in one IR operation. It is useful for targets that support compressing store operations and allows vectorizing loops with cross-iteration dependencies like in the following example:

.. code-block:: c

Expand Down Expand Up @@ -26584,7 +26584,7 @@ Semantics:

The '``llvm.set.fpenv``' intrinsic sets the current floating-point environment
to the state specified by the argument. The state may be previously obtained by a
call to '``llvm.get.fpenv``' or synthesised in a platform-dependent way.
call to '``llvm.get.fpenv``' or synthesized in a platform-dependent way.


'``llvm.reset.fpenv``' Intrinsic
Expand Down Expand Up @@ -27007,7 +27007,7 @@ This intrinsic is lowered to code which is intended to cause an execution trap,
embedding the argument into encoding of that trap somehow to discriminate
crashes if possible.

Equivalent to ``@llvm.trap`` for targets that do not support this behaviour.
Equivalent to ``@llvm.trap`` for targets that do not support this behavior.

'``llvm.stackprotector``' Intrinsic
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Expand Down Expand Up @@ -27948,7 +27948,7 @@ Arguments:
The first three arguments are the same as they are in the :ref:`@llvm.memcpy <int_memcpy>`
intrinsic, with the added constraint that ``len`` is required to be a positive integer
multiple of the ``element_size``. If ``len`` is not a positive integer multiple of
``element_size``, then the behaviour of the intrinsic is undefined.
``element_size``, then the behavior of the intrinsic is undefined.

``element_size`` must be a compile-time constant positive power of two no greater than
target-specific atomic access size limit.
Expand Down Expand Up @@ -28024,7 +28024,7 @@ The first three arguments are the same as they are in the
:ref:`@llvm.memmove <int_memmove>` intrinsic, with the added constraint that
``len`` is required to be a positive integer multiple of the ``element_size``.
If ``len`` is not a positive integer multiple of ``element_size``, then the
behaviour of the intrinsic is undefined.
behavior of the intrinsic is undefined.

``element_size`` must be a compile-time constant positive power of two no
greater than a target-specific atomic access size limit.
Expand Down Expand Up @@ -28103,7 +28103,7 @@ Arguments:
The first three arguments are the same as they are in the :ref:`@llvm.memset <int_memset>`
intrinsic, with the added constraint that ``len`` is required to be a positive integer
multiple of the ``element_size``. If ``len`` is not a positive integer multiple of
``element_size``, then the behaviour of the intrinsic is undefined.
``element_size``, then the behavior of the intrinsic is undefined.

``element_size`` must be a compile-time constant positive power of two no greater than
target-specific atomic access size limit.
Expand Down