@@ -354,7 +354,7 @@ added in the future:
354354 not be used lightly but only for specific situations such as an
355355 alternative to the *register pinning* performance technique often
356356 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
358358 following limitations exist:
359359
360360 - 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
685685challenging as many commonly expected properties, such as
686686``ptrtoint(v)-ptrtoint(v) == 0``, don't hold for non-integral types.
687687Similar 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>`.
689689
690690The 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
692692representation of the pointer.
693693
694694.. _globalvars:
@@ -1677,10 +1677,10 @@ Currently, only the following parameter attributes are defined:
16771677 - The range is allowed to wrap.
16781678 - The empty range is represented using ``0,0``.
16791679 - 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
16821682 or vector of integer types.
1683-
1683+
16841684 For vector-typed parameters, the range is applied element-wise.
16851685
16861686.. _gc:
@@ -3050,6 +3050,19 @@ as follows:
30503050 address space 0, this property only affects the default value to be used
30513051 when creating globals without additional contextual information (e.g. in
30523052 LLVM passes).
3053+ ``T<address space>``
3054+ Specifies the address space for a target's 'flat' address space. Note this
3055+ is not necessarily the same as addrspace 0, which LLVM sometimes refers to
3056+ as the generic address space. The flat address space is a generic address
3057+ space that can be used access multiple segments of memory with different
3058+ address spaces. Access of a memory location through a pointer with this
3059+ address space is expected to be legal but slower compared to the same memory
3060+ location accessed through a pointer with a different address space. This is
3061+ for targets with different pointer representations which can be converted
3062+ with the addrspacecast instruction. If a pointer is converted to this
3063+ address space, optimizations should attempt to replace the access with the
3064+ source address space. The absence of this specification indicates the target
3065+ does not have such a flat address space to optimize away.
30533066
30543067.. _alloca_addrspace:
30553068
@@ -14346,7 +14359,7 @@ Arguments:
1434614359""""""""""
1434714360The first 4 arguments are similar to ``llvm.instrprof.increment``. The indexing
1434814361is specific to callsites, meaning callsites are indexed from 0, independent from
14349- the indexes used by the other intrinsics (such as
14362+ the indexes used by the other intrinsics (such as
1435014363``llvm.instrprof.increment[.step]``).
1435114364
1435214365The last argument is the called value of the callsite this intrinsic precedes.
@@ -14360,7 +14373,7 @@ a buffer LLVM can use to perform counter increments (i.e. the lowering of
1436014373``llvm.instrprof.increment[.step]``. The address range following the counter
1436114374buffer, ``<num-counters>`` x ``sizeof(ptr)`` - sized, is expected to contain
1436214375pointers to contexts of functions called from this function ("subcontexts").
14363- LLVM does not dereference into that memory region, just calculates GEPs.
14376+ LLVM does not dereference into that memory region, just calculates GEPs.
1436414377
1436514378The lowering of ``llvm.instrprof.callsite`` consists of:
1436614379
@@ -14929,8 +14942,8 @@ integer bit width or any vector of integer elements.
1492914942Overview:
1493014943"""""""""
1493114944
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.
14945+ Return ``-1`` if ``%a`` is signed less than ``%b``, ``0`` if they are equal, and
14946+ ``1`` if ``%a`` is signed greater than ``%b``. Vector intrinsics operate on a per-element basis.
1493414947
1493514948Arguments:
1493614949""""""""""
@@ -14958,8 +14971,8 @@ integer bit width or any vector of integer elements.
1495814971Overview:
1495914972"""""""""
1496014973
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.
14974+ Return ``-1`` if ``%a`` is unsigned less than ``%b``, ``0`` if they are equal, and
14975+ ``1`` if ``%a`` is unsigned greater than ``%b``. Vector intrinsics operate on a per-element basis.
1496314976
1496414977Arguments:
1496514978""""""""""
@@ -21556,9 +21569,9 @@ Semantics:
2155621569""""""""""
2155721570
2155821571The '``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
21572+ of the first and second vector arguments on each enabled lane, the result being
2156021573NaN 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>`.
21574+ intrinsic. The result on disabled lanes is a :ref:`poison value <poisonvalues>`.
2156221575The operation is performed in the default floating-point environment.
2156321576
2156421577Examples:
@@ -29191,7 +29204,7 @@ Semantics:
2919129204""""""""""
2919229205
2919329206The intrinsic ``@llvm.allow.ubsan.check()`` returns either ``true`` or
29194- ``false``, depending on compiler options.
29207+ ``false``, depending on compiler options.
2919529208
2919629209For each evaluation of a call to this intrinsic, the program must be valid and
2919729210correct both if it returns ``true`` and if it returns ``false``.
@@ -29250,13 +29263,13 @@ Semantics:
2925029263""""""""""
2925129264
2925229265The intrinsic ``@llvm.allow.runtime.check()`` returns either ``true`` or
29253- ``false``, depending on compiler options.
29266+ ``false``, depending on compiler options.
2925429267
2925529268For each evaluation of a call to this intrinsic, the program must be valid and
2925629269correct both if it returns ``true`` and if it returns ``false``.
2925729270
2925829271When used in a branch condition, it allows us to choose between
29259- two alternative correct solutions for the same problem.
29272+ two alternative correct solutions for the same problem.
2926029273
2926129274If the intrinsic is evaluated as ``true``, program should execute a guarded
2926229275check. If the intrinsic is evaluated as ``false``, the program should avoid any
0 commit comments