@@ -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:
@@ -14347,7 +14347,7 @@ Arguments:
14347
14347
""""""""""
14348
14348
The first 4 arguments are similar to ``llvm.instrprof.increment``. The indexing
14349
14349
is specific to callsites, meaning callsites are indexed from 0, independent from
14350
- the indexes used by the other intrinsics (such as
14350
+ the indexes used by the other intrinsics (such as
14351
14351
``llvm.instrprof.increment[.step]``).
14352
14352
14353
14353
The last argument is the called value of the callsite this intrinsic precedes.
@@ -14361,7 +14361,7 @@ a buffer LLVM can use to perform counter increments (i.e. the lowering of
14361
14361
``llvm.instrprof.increment[.step]``. The address range following the counter
14362
14362
buffer, ``<num-counters>`` x ``sizeof(ptr)`` - sized, is expected to contain
14363
14363
pointers to contexts of functions called from this function ("subcontexts").
14364
- LLVM does not dereference into that memory region, just calculates GEPs.
14364
+ LLVM does not dereference into that memory region, just calculates GEPs.
14365
14365
14366
14366
The lowering of ``llvm.instrprof.callsite`` consists of:
14367
14367
@@ -14930,8 +14930,8 @@ integer bit width or any vector of integer elements.
14930
14930
Overview:
14931
14931
"""""""""
14932
14932
14933
- Return ``-1`` if ``%a`` is signed less than ``%b``, ``0`` if they are equal, and
14934
- ``1`` if ``%a`` is signed greater than ``%b``. Vector intrinsics operate on a per-element basis.
14933
+ Return ``-1`` if ``%a`` is signed less than ``%b``, ``0`` if they are equal, and
14934
+ ``1`` if ``%a`` is signed greater than ``%b``. Vector intrinsics operate on a per-element basis.
14935
14935
14936
14936
Arguments:
14937
14937
""""""""""
@@ -14959,8 +14959,8 @@ integer bit width or any vector of integer elements.
14959
14959
Overview:
14960
14960
"""""""""
14961
14961
14962
- Return ``-1`` if ``%a`` is unsigned less than ``%b``, ``0`` if they are equal, and
14963
- ``1`` if ``%a`` is unsigned greater than ``%b``. Vector intrinsics operate on a per-element basis.
14962
+ Return ``-1`` if ``%a`` is unsigned less than ``%b``, ``0`` if they are equal, and
14963
+ ``1`` if ``%a`` is unsigned greater than ``%b``. Vector intrinsics operate on a per-element basis.
14964
14964
14965
14965
Arguments:
14966
14966
""""""""""
@@ -21557,9 +21557,9 @@ Semantics:
21557
21557
""""""""""
21558
21558
21559
21559
The '``llvm.vp.minimum``' intrinsic performs floating-point minimum (:ref:`minimum <i_minimum>`)
21560
- of the first and second vector arguments on each enabled lane, the result being
21560
+ of the first and second vector arguments on each enabled lane, the result being
21561
21561
NaN if either argument is a NaN. -0.0 is considered to be less than +0.0 for this
21562
- intrinsic. The result on disabled lanes is a :ref:`poison value <poisonvalues>`.
21562
+ intrinsic. The result on disabled lanes is a :ref:`poison value <poisonvalues>`.
21563
21563
The operation is performed in the default floating-point environment.
21564
21564
21565
21565
Examples:
@@ -29192,7 +29192,7 @@ Semantics:
29192
29192
""""""""""
29193
29193
29194
29194
The intrinsic ``@llvm.allow.ubsan.check()`` returns either ``true`` or
29195
- ``false``, depending on compiler options.
29195
+ ``false``, depending on compiler options.
29196
29196
29197
29197
For each evaluation of a call to this intrinsic, the program must be valid and
29198
29198
correct both if it returns ``true`` and if it returns ``false``.
@@ -29251,13 +29251,13 @@ Semantics:
29251
29251
""""""""""
29252
29252
29253
29253
The intrinsic ``@llvm.allow.runtime.check()`` returns either ``true`` or
29254
- ``false``, depending on compiler options.
29254
+ ``false``, depending on compiler options.
29255
29255
29256
29256
For each evaluation of a call to this intrinsic, the program must be valid and
29257
29257
correct both if it returns ``true`` and if it returns ``false``.
29258
29258
29259
29259
When used in a branch condition, it allows us to choose between
29260
- two alternative correct solutions for the same problem.
29260
+ two alternative correct solutions for the same problem.
29261
29261
29262
29262
If the intrinsic is evaluated as ``true``, program should execute a guarded
29263
29263
check. If the intrinsic is evaluated as ``false``, the program should avoid any
0 commit comments