@@ -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,25 @@ 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 'flat' address space for a target. Some targets may have an
3055+ address space that allows access to multiple memory segments, each with
3056+ distinct address spaces. Accessing memory through a pointer in this address
3057+ space is valid but may be slower than using a pointer with a more specific
3058+ address space. When a pointer is converted to this address space,
3059+ optimizations can attempt to replace the access with one using the original
3060+ address space. This is the 'flat' address space. It is intended for targets
3061+ with varying pointer representations, which can be converted using the
3062+ addrspacecast instruction. It is important to note that the flat address
3063+ space is not always equivalent to address space 0, which LLVM commonly
3064+ refers to as the generic address space. For instance, in SPIR and SPIR-V,
3065+ address space 4 is designated as the flat address space. Additionally, the
3066+ flat address space must correspond to an existing address space of the
3067+ target. Specifying an address space as 'flat' address space does not change
3068+ any inherent characteristics of the original address spaces, nor does it
3069+ guarantee any additional properties. If this specification is absent, it
3070+ indicates that the target does not support a flat address space for
3071+ optimization.
30533072
30543073.. _alloca_addrspace:
30553074
@@ -14346,7 +14365,7 @@ Arguments:
1434614365""""""""""
1434714366The first 4 arguments are similar to ``llvm.instrprof.increment``. The indexing
1434814367is specific to callsites, meaning callsites are indexed from 0, independent from
14349- the indexes used by the other intrinsics (such as
14368+ the indexes used by the other intrinsics (such as
1435014369``llvm.instrprof.increment[.step]``).
1435114370
1435214371The last argument is the called value of the callsite this intrinsic precedes.
@@ -14360,7 +14379,7 @@ a buffer LLVM can use to perform counter increments (i.e. the lowering of
1436014379``llvm.instrprof.increment[.step]``. The address range following the counter
1436114380buffer, ``<num-counters>`` x ``sizeof(ptr)`` - sized, is expected to contain
1436214381pointers to contexts of functions called from this function ("subcontexts").
14363- LLVM does not dereference into that memory region, just calculates GEPs.
14382+ LLVM does not dereference into that memory region, just calculates GEPs.
1436414383
1436514384The lowering of ``llvm.instrprof.callsite`` consists of:
1436614385
@@ -14929,8 +14948,8 @@ integer bit width or any vector of integer elements.
1492914948Overview:
1493014949"""""""""
1493114950
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.
14951+ Return ``-1`` if ``%a`` is signed less than ``%b``, ``0`` if they are equal, and
14952+ ``1`` if ``%a`` is signed greater than ``%b``. Vector intrinsics operate on a per-element basis.
1493414953
1493514954Arguments:
1493614955""""""""""
@@ -14958,8 +14977,8 @@ integer bit width or any vector of integer elements.
1495814977Overview:
1495914978"""""""""
1496014979
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.
14980+ Return ``-1`` if ``%a`` is unsigned less than ``%b``, ``0`` if they are equal, and
14981+ ``1`` if ``%a`` is unsigned greater than ``%b``. Vector intrinsics operate on a per-element basis.
1496314982
1496414983Arguments:
1496514984""""""""""
@@ -21556,9 +21575,9 @@ Semantics:
2155621575""""""""""
2155721576
2155821577The '``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
21578+ of the first and second vector arguments on each enabled lane, the result being
2156021579NaN 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>`.
21580+ intrinsic. The result on disabled lanes is a :ref:`poison value <poisonvalues>`.
2156221581The operation is performed in the default floating-point environment.
2156321582
2156421583Examples:
@@ -29191,7 +29210,7 @@ Semantics:
2919129210""""""""""
2919229211
2919329212The intrinsic ``@llvm.allow.ubsan.check()`` returns either ``true`` or
29194- ``false``, depending on compiler options.
29213+ ``false``, depending on compiler options.
2919529214
2919629215For each evaluation of a call to this intrinsic, the program must be valid and
2919729216correct both if it returns ``true`` and if it returns ``false``.
@@ -29250,13 +29269,13 @@ Semantics:
2925029269""""""""""
2925129270
2925229271The intrinsic ``@llvm.allow.runtime.check()`` returns either ``true`` or
29253- ``false``, depending on compiler options.
29272+ ``false``, depending on compiler options.
2925429273
2925529274For each evaluation of a call to this intrinsic, the program must be valid and
2925629275correct both if it returns ``true`` and if it returns ``false``.
2925729276
2925829277When used in a branch condition, it allows us to choose between
29259- two alternative correct solutions for the same problem.
29278+ two alternative correct solutions for the same problem.
2926029279
2926129280If the intrinsic is evaluated as ``true``, program should execute a guarded
2926229281check. If the intrinsic is evaluated as ``false``, the program should avoid any
0 commit comments