@@ -354,7 +354,7 @@ added in the future:
354
354
not be used lightly but only for specific situations such as an
355
355
alternative to the *register pinning* performance technique often
356
356
used when implementing functional programming languages. At the
357
- moment only X86, AArch64, and RISCV support this convention. The
357
+ moment only X86, AArch64, and RISCV support this convention. The
358
358
following limitations exist:
359
359
360
360
- On *X86-32* only up to 4 bit type parameters are supported. No
@@ -685,10 +685,10 @@ implementation defined, the optimizer can't do the latter. The former is
685
685
challenging as many commonly expected properties, such as
686
686
``ptrtoint(v)-ptrtoint(v) == 0``, don't hold for non-integral types.
687
687
Similar restrictions apply to intrinsics that might examine the pointer bits,
688
- such as :ref:`llvm.ptrmask<int_ptrmask>`.
688
+ such as :ref:`llvm.ptrmask<int_ptrmask>`.
689
689
690
690
The alignment information provided by the frontend for a non-integral pointer
691
- (typically using attributes or metadata) must be valid for every possible
691
+ (typically using attributes or metadata) must be valid for every possible
692
692
representation of the pointer.
693
693
694
694
.. _globalvars:
@@ -1677,10 +1677,10 @@ Currently, only the following parameter attributes are defined:
1677
1677
- The range is allowed to wrap.
1678
1678
- The empty range is represented using ``0,0``.
1679
1679
- Otherwise, ``a`` and ``b`` are not allowed to be equal.
1680
-
1681
- This attribute may only be applied to parameters or return values with integer
1680
+
1681
+ This attribute may only be applied to parameters or return values with integer
1682
1682
or vector of integer types.
1683
-
1683
+
1684
1684
For vector-typed parameters, the range is applied element-wise.
1685
1685
1686
1686
.. _gc:
@@ -14346,7 +14346,7 @@ Arguments:
14346
14346
""""""""""
14347
14347
The first 4 arguments are similar to ``llvm.instrprof.increment``. The indexing
14348
14348
is specific to callsites, meaning callsites are indexed from 0, independent from
14349
- the indexes used by the other intrinsics (such as
14349
+ the indexes used by the other intrinsics (such as
14350
14350
``llvm.instrprof.increment[.step]``).
14351
14351
14352
14352
The last argument is the called value of the callsite this intrinsic precedes.
@@ -14360,7 +14360,7 @@ a buffer LLVM can use to perform counter increments (i.e. the lowering of
14360
14360
``llvm.instrprof.increment[.step]``. The address range following the counter
14361
14361
buffer, ``<num-counters>`` x ``sizeof(ptr)`` - sized, is expected to contain
14362
14362
pointers to contexts of functions called from this function ("subcontexts").
14363
- LLVM does not dereference into that memory region, just calculates GEPs.
14363
+ LLVM does not dereference into that memory region, just calculates GEPs.
14364
14364
14365
14365
The lowering of ``llvm.instrprof.callsite`` consists of:
14366
14366
@@ -14929,8 +14929,8 @@ integer bit width or any vector of integer elements.
14929
14929
Overview:
14930
14930
"""""""""
14931
14931
14932
- Return ``-1`` if ``%a`` is signed less than ``%b``, ``0`` if they are equal, and
14933
- ``1`` if ``%a`` is signed greater than ``%b``. Vector intrinsics operate on a per-element basis.
14932
+ Return ``-1`` if ``%a`` is signed less than ``%b``, ``0`` if they are equal, and
14933
+ ``1`` if ``%a`` is signed greater than ``%b``. Vector intrinsics operate on a per-element basis.
14934
14934
14935
14935
Arguments:
14936
14936
""""""""""
@@ -14958,8 +14958,8 @@ integer bit width or any vector of integer elements.
14958
14958
Overview:
14959
14959
"""""""""
14960
14960
14961
- Return ``-1`` if ``%a`` is unsigned less than ``%b``, ``0`` if they are equal, and
14962
- ``1`` if ``%a`` is unsigned greater than ``%b``. Vector intrinsics operate on a per-element basis.
14961
+ Return ``-1`` if ``%a`` is unsigned less than ``%b``, ``0`` if they are equal, and
14962
+ ``1`` if ``%a`` is unsigned greater than ``%b``. Vector intrinsics operate on a per-element basis.
14963
14963
14964
14964
Arguments:
14965
14965
""""""""""
@@ -21556,9 +21556,9 @@ Semantics:
21556
21556
""""""""""
21557
21557
21558
21558
The '``llvm.vp.minimum``' intrinsic performs floating-point minimum (:ref:`minimum <i_minimum>`)
21559
- of the first and second vector arguments on each enabled lane, the result being
21559
+ of the first and second vector arguments on each enabled lane, the result being
21560
21560
NaN if either argument is a NaN. -0.0 is considered to be less than +0.0 for this
21561
- intrinsic. The result on disabled lanes is a :ref:`poison value <poisonvalues>`.
21561
+ intrinsic. The result on disabled lanes is a :ref:`poison value <poisonvalues>`.
21562
21562
The operation is performed in the default floating-point environment.
21563
21563
21564
21564
Examples:
@@ -29191,7 +29191,7 @@ Semantics:
29191
29191
""""""""""
29192
29192
29193
29193
The intrinsic ``@llvm.allow.ubsan.check()`` returns either ``true`` or
29194
- ``false``, depending on compiler options.
29194
+ ``false``, depending on compiler options.
29195
29195
29196
29196
For each evaluation of a call to this intrinsic, the program must be valid and
29197
29197
correct both if it returns ``true`` and if it returns ``false``.
@@ -29250,13 +29250,13 @@ Semantics:
29250
29250
""""""""""
29251
29251
29252
29252
The intrinsic ``@llvm.allow.runtime.check()`` returns either ``true`` or
29253
- ``false``, depending on compiler options.
29253
+ ``false``, depending on compiler options.
29254
29254
29255
29255
For each evaluation of a call to this intrinsic, the program must be valid and
29256
29256
correct both if it returns ``true`` and if it returns ``false``.
29257
29257
29258
29258
When used in a branch condition, it allows us to choose between
29259
- two alternative correct solutions for the same problem.
29259
+ two alternative correct solutions for the same problem.
29260
29260
29261
29261
If the intrinsic is evaluated as ``true``, program should execute a guarded
29262
29262
check. If the intrinsic is evaluated as ``false``, the program should avoid any
0 commit comments