diff options
Diffstat (limited to 'llvm/docs/LangRef.rst')
| -rw-r--r-- | llvm/docs/LangRef.rst | 136 |
1 files changed, 68 insertions, 68 deletions
diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst index 1c6823b..54c7d0f 100644 --- a/llvm/docs/LangRef.rst +++ b/llvm/docs/LangRef.rst @@ -159,7 +159,7 @@ There are two kinds of escapes. * ``\\`` represents a single ``\`` character. * ``\`` followed by two hexadecimal characters (0-9, a-f, or A-F) - represents the byte with the given value (e.g. ``\00`` represents a + represents the byte with the given value (e.g., ``\00`` represents a null byte). To represent a ``"`` character, use ``\22``. (``\"`` will end the string @@ -168,7 +168,7 @@ with a trailing ``\``.) Newlines do not terminate string constants; strings can span multiple lines. -The interpretation of string constants (e.g. their character encoding) +The interpretation of string constants (e.g., their character encoding) depends on context. @@ -330,7 +330,7 @@ added in the future: the function (as does normal C). "``fastcc``" - The fast calling convention This calling convention attempts to make calls as fast as possible - (e.g. by passing things in registers). This calling convention + (e.g., by passing things in registers). This calling convention allows the target to use whatever tricks it wants to produce fast code for the target, without having to conform to an externally specified ABI (Application Binary Interface). `Tail calls can only @@ -465,7 +465,7 @@ added in the future: This calling convention doesn't preserve any general registers. So all general registers are caller saved registers. It also uses all general registers to pass arguments. This attribute doesn't impact non-general - purpose registers (e.g. floating point registers, on X86 XMMs/YMMs). + purpose registers (e.g., floating point registers, on X86 XMMs/YMMs). Non-general purpose registers still follow the standard C calling convention. Currently it is for x86_64 and AArch64 only. "``cxx_fast_tlscc``" - The `CXX_FAST_TLS` calling convention for access functions @@ -700,7 +700,7 @@ Unstable pointer representation ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Pointers in this address space have an *unspecified* bitwise representation -(i.e. not backed by a fixed integer). The bitwise pattern of such pointers is +(i.e., not backed by a fixed integer). The bitwise pattern of such pointers is allowed to change in a target-specific way. For example, this could be a pointer type used with copying garbage collection where the garbage collector could update the pointer at any time in the collection sweep. @@ -903,7 +903,7 @@ size is unknown at compile time. They are allowed in structs to facilitate intrinsics returning multiple values. Generally, structs containing scalable vectors are not considered "sized" and cannot be used in loads, stores, allocas, or GEPs. The only exception to this rule is for structs that contain scalable -vectors of the same type (e.g. ``{<vscale x 2 x i32>, <vscale x 2 x i32>}`` +vectors of the same type (e.g., ``{<vscale x 2 x i32>, <vscale x 2 x i32>}`` contains the same type while ``{<vscale x 2 x i32>, <vscale x 2 x i64>}`` doesn't). These kinds of structs (we may call them homogeneous scalable vector structs) are considered sized and can be used in loads, stores, allocas, but @@ -1221,7 +1221,7 @@ sections. Note that certain IR constructs like global variables and functions may create COMDATs in the object file in addition to any which are specified using COMDAT IR. This arises when the code generator is configured to emit globals -in individual sections (e.g. when `-data-sections` or `-function-sections` +in individual sections (e.g., when `-data-sections` or `-function-sections` is supplied to `llc`). .. _namedmetadatastructure: @@ -1722,7 +1722,7 @@ Currently, only the following parameter attributes are defined: The function parameter marked with this attribute is the alignment in bytes of the newly allocated block returned by this function. The returned value must either have the specified alignment or be the null pointer. The return value MAY be more aligned - than the requested alignment, but not less aligned. Invalid (e.g. non-power-of-2) + than the requested alignment, but not less aligned. Invalid (e.g., non-power-of-2) alignments are permitted for the allocalign parameter, so long as the returned pointer is null. This attribute may only be applied to integer parameters. @@ -1989,7 +1989,7 @@ functions will use the same set of attributes. In the degenerate case of a group will capture the important command line flags used to build that file. An attribute group is a module-level object. To use an attribute group, an -object references the attribute group's ID (e.g. ``#37``). An object may refer +object references the attribute group's ID (e.g., ``#37``). An object may refer to more than one attribute group. In that situation, the attributes from the different groups are merged. @@ -2222,7 +2222,7 @@ For example: - ``errnomem``: This refers to accesses to the ``errno`` variable. - The default access kind (specified without a location prefix) applies to all locations that haven't been specified explicitly, including those that - don't currently have a dedicated location kind (e.g. accesses to globals + don't currently have a dedicated location kind (e.g., accesses to globals or captured pointers). If the ``memory`` attribute is not specified, then ``memory(readwrite)`` @@ -2713,7 +2713,7 @@ For example: ``mustprogress`` This attribute indicates that the function is required to return, unwind, - or interact with the environment in an observable way e.g. via a volatile + or interact with the environment in an observable way e.g., via a volatile memory access, I/O, or other synchronization. The ``mustprogress`` attribute is intended to model the requirements of the first section of [intro.progress] of the C++ Standard. As a consequence, a loop in a @@ -2851,7 +2851,7 @@ are grouped into a single :ref:`attribute group <attrgrp>`. with `__attribute__((no_sanitize("memtag")))`, `__attribute__((disable_sanitizer_instrumentation))`, or included in the `-fsanitize-ignorelist` file. The AArch64 Globals Tagging pass may remove - this attribute when it's not possible to tag the global (e.g. it's a TLS + this attribute when it's not possible to tag the global (e.g., it's a TLS variable). ``sanitize_address_dyninit`` This attribute indicates that the global variable, when instrumented with @@ -3076,7 +3076,7 @@ the behavior is undefined, unless one of the following exceptions applies: * ``dereferenceable(<n>)`` operand bundles only guarantee the pointer is dereferenceable at the point of the assumption. The pointer may not be - dereferenceable at later pointers, e.g. because it could have been freed. + dereferenceable at later pointers, e.g., because it could have been freed. In addition to allowing operand bundles encoding function and parameter attributes, an assume operand bundle may also encode a ``separate_storage`` @@ -3270,7 +3270,7 @@ as follows: address space 0. Note: variable declarations without an address space are always created in address space 0, this property only affects the default value to be used - when creating globals without additional contextual information (e.g. in + when creating globals without additional contextual information (e.g., in LLVM passes). .. _alloca_addrspace: @@ -3282,7 +3282,7 @@ as follows: This specifies the properties of a pointer in address space ``as``. The ``<size>`` parameter specifies the size of the bitwise representation. For :ref:`non-integral pointers <nointptrtype>` the representation size may - be larger than the address width of the underlying address space (e.g. to + be larger than the address width of the underlying address space (e.g., to accommodate additional metadata). The alignment requirements are specified via the ``<abi>`` and ``<pref>``\erred alignments parameters. @@ -3478,7 +3478,7 @@ variables) may *not* change their size. (``realloc``-style operations do not change the size of an existing allocated object; instead, they create a new allocated object. Even if the object is at the same location as the old one, old pointers cannot be used to access this new object.) However, allocated objects -can also be created by means not recognized by LLVM, e.g. by directly calling +can also be created by means not recognized by LLVM, e.g., by directly calling ``mmap``. Those allocated objects are allowed to grow to the right (i.e., keeping the same base address, but increasing their size) while maintaining the validity of existing pointers, as long as they always satisfy the properties @@ -3632,7 +3632,7 @@ through the return value only: } However, we always consider direct inspection of the pointer address -(e.g. using ``ptrtoint``) to be location-independent. The following example +(e.g., using ``ptrtoint``) to be location-independent. The following example is *not* considered a return-only capture, even though the ``ptrtoint`` ultimately only contributes to the return value: @@ -4145,7 +4145,7 @@ output, given the original flags. ``a * (c / b)`` can be rewritten into ``a / (b / c)``. ``contract`` - Allow floating-point contraction (e.g. fusing a multiply followed by an + Allow floating-point contraction (e.g., fusing a multiply followed by an 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. @@ -4440,7 +4440,7 @@ the default globals address space and ``addrspace("P")`` the program address space. The representation of pointers can be different for each address space and does -not necessarily need to be a plain integer address (e.g. for +not necessarily need to be a plain integer address (e.g., for :ref:`non-integral pointers <nointptrtype>`). In addition to a representation bits size, pointers in each address space also have an index size which defines the bitwidth of indexing operations as well as the size of `integer addresses` @@ -4750,7 +4750,7 @@ is inserted as defined by the DataLayout string in the module, which is required to match what the underlying code generator expects. Structures can either be "literal" or "identified". A literal structure -is defined inline with other types (e.g. ``[2 x {i32, i32}]``) whereas +is defined inline with other types (e.g., ``[2 x {i32, i32}]``) whereas identified types are always defined at the top level with a name. Literal types are uniqued by their contents and can never be recursive or opaque since there is no way to write one. Identified types can be @@ -4791,7 +4791,7 @@ Simple Constants Standard integers (such as '4') are constants of the :ref:`integer <t_integer>` type. They can be either decimal or hexadecimal. Decimal integers can be prefixed with - to represent - negative integers, e.g. '``-1234``'. Hexadecimal integers must be + negative integers, e.g., '``-1234``'. Hexadecimal integers must be prefixed with either u or s to indicate whether they are unsigned or signed respectively. e.g '``u0x8000``' gives 32768, whilst '``s0x8000``' gives -32768. @@ -4801,7 +4801,7 @@ Simple Constants zeros. So '``s0x0001``' of type '``i16``' will be -1, not 1. **Floating-point constants** Floating-point constants use standard decimal notation (e.g. - 123.421), exponential notation (e.g. 1.23421e+2), or a more precise + 123.421), exponential notation (e.g., 1.23421e+2), or a more precise hexadecimal notation (see below). The assembler requires the exact decimal value of a floating-point constant. For example, the assembler accepts 1.25 but rejects 1.3 because 1.3 is a repeating @@ -4883,7 +4883,7 @@ constants and smaller complex constants. The string '``zeroinitializer``' can be used to zero initialize a value to zero of *any* type, including scalar and :ref:`aggregate <t_aggregate>` types. This is often used to avoid - having to print large zero initializers (e.g. for large arrays) and + having to print large zero initializers (e.g., for large arrays) and is always exactly equivalent to using explicit zero initializers. **Metadata node** A metadata node is a constant tuple without types. For example: @@ -5286,7 +5286,7 @@ Constant Expressions Constant expressions are used to allow expressions involving other constants to be used as constants. Constant expressions may be of any :ref:`first class <t_firstclass>` type and may involve any LLVM operation -that does not have side effects (e.g. load and call are not supported). +that does not have side effects (e.g., load and call are not supported). The following is the syntax for constant expressions: ``trunc (CST to TYPE)`` @@ -5472,7 +5472,7 @@ There are also three different categories of constraint codes: Output constraints """""""""""""""""" -Output constraints are specified by an "``=``" prefix (e.g. "``=r``"). This +Output constraints are specified by an "``=``" prefix (e.g., "``=r``"). This indicates that the assembly will write to this operand, and the operand will then be made available as a return value of the ``asm`` expression. Output constraints do not consume an argument from the call instruction. (Except, see @@ -5480,10 +5480,10 @@ below about indirect outputs). Normally, it is expected that no output locations are written to by the assembly expression until *all* of the inputs have been read. As such, LLVM may assign -the same register to an output and an input. If this is not safe (e.g. if the +the same register to an output and an input. If this is not safe (e.g., if the assembly contains two instructions, where the first writes to one output, and the second reads an input and writes to a second output), then the "``&``" -modifier must be used (e.g. "``=&r``") to specify that the output is an +modifier must be used (e.g., "``=&r``") to specify that the output is an "early-clobber" output. Marking an output as "early-clobber" ensures that LLVM will not use the same register for any inputs (other than an input tied to this output). @@ -5523,17 +5523,17 @@ However, this feature is often not as useful as you might think. Firstly, the registers are *not* guaranteed to be consecutive. So, on those architectures that have instructions which operate on multiple consecutive -instructions, this is not an appropriate way to support them. (e.g. the 32-bit +instructions, this is not an appropriate way to support them. (e.g., the 32-bit SparcV8 has a 64-bit load, which instruction takes a single 32-bit register. The hardware then loads into both the named register, and the next register. This feature of inline asm would not be useful to support that.) A few of the targets provide a template string modifier allowing explicit access -to the second register of a two-register operand (e.g. MIPS ``L``, ``M``, and +to the second register of a two-register operand (e.g., MIPS ``L``, ``M``, and ``D``). On such an architecture, you can actually access the second allocated register (yet, still, not any subsequent ones). But, in that case, you're still probably better off simply splitting the value into two separate operands, for -clarity. (e.g. see the description of the ``A`` constraint on X86, which, +clarity. (e.g., see the description of the ``A`` constraint on X86, which, despite existing only for use with this feature, is not really a good idea to use) @@ -5549,11 +5549,11 @@ rather than producing a return value. An indirect output constraint is an "output" only in that the asm is expected to write to the contents of the input memory location, instead of just read from it). -This is most typically used for memory constraint, e.g. "``=*m``", to pass the +This is most typically used for memory constraint, e.g., "``=*m``", to pass the address of a variable as a value. It is also possible to use an indirect *register* constraint, but only on output -(e.g. "``=*r``"). This will cause LLVM to allocate a register for an output +(e.g., "``=*r``"). This will cause LLVM to allocate a register for an output value normally, and then, separately emit a store to the address provided as input, after the provided inline asm. (It's not clear what value this functionality provides, compared to writing the store explicitly after the asm @@ -5570,7 +5570,7 @@ Clobber constraints A clobber constraint is indicated by a "``~``" prefix. A clobber does not consume an input operand, nor generate an output. Clobbers cannot use any of the general constraint code letters -- they may use only explicit register -constraints, e.g. "``~{eax}``". The one exception is that a clobber string of +constraints, e.g., "``~{eax}``". The one exception is that a clobber string of "``~{memory}``" indicates that the assembly writes to arbitrary undeclared memory locations -- not only the memory pointed to by a declared indirect output. @@ -5594,9 +5594,9 @@ Constraint Codes """""""""""""""" After a potential prefix comes constraint code, or codes. -A Constraint Code is either a single letter (e.g. "``r``"), a "``^``" character -followed by two letters (e.g. "``^wc``"), or "``{``" register-name "``}``" -(e.g. "``{eax}``"). +A Constraint Code is either a single letter (e.g., "``r``"), a "``^``" character +followed by two letters (e.g., "``^wc``"), or "``{``" register-name "``}``" +(e.g., "``{eax}``"). The one and two letter constraint codes are typically chosen to be the same as GCC's constraint codes. @@ -5973,11 +5973,11 @@ Target-independent: - ``a``: Print a memory reference. Targets might customize the output. - ``c``: Print an immediate integer constant unadorned, without - the target-specific immediate punctuation (e.g. no ``$`` prefix). + the target-specific immediate punctuation (e.g., no ``$`` prefix). - ``n``: Negate and print immediate integer constant unadorned, without the - target-specific immediate punctuation (e.g. no ``$`` prefix). + target-specific immediate punctuation (e.g., no ``$`` prefix). - ``l``: Print as an unadorned label, without the target-specific label - punctuation (e.g. no ``$`` prefix). + punctuation (e.g., no ``$`` prefix). AArch64: @@ -5998,7 +5998,7 @@ ARM: register). - ``P``: No effect. - ``q``: No effect. -- ``y``: Print a VFP single-precision register as an indexed double (e.g. print +- ``y``: Print a VFP single-precision register as an indexed double (e.g., print as ``d4[1]`` instead of ``s9``) - ``B``: Bitwise invert and print an immediate integer constant without ``#`` prefix. @@ -6114,18 +6114,18 @@ X86: - ``c``: Print an unadorned integer or symbol name. (The latter is target-specific behavior for this typically target-independent modifier). - ``A``: Print a register name with a '``*``' before it. -- ``b``: Print an 8-bit register name (e.g. ``al``); do nothing on a memory +- ``b``: Print an 8-bit register name (e.g., ``al``); do nothing on a memory operand. -- ``h``: Print the upper 8-bit register name (e.g. ``ah``); do nothing on a +- ``h``: Print the upper 8-bit register name (e.g., ``ah``); do nothing on a memory operand. -- ``w``: Print the 16-bit register name (e.g. ``ax``); do nothing on a memory +- ``w``: Print the 16-bit register name (e.g., ``ax``); do nothing on a memory operand. -- ``k``: Print the 32-bit register name (e.g. ``eax``); do nothing on a memory +- ``k``: Print the 32-bit register name (e.g., ``eax``); do nothing on a memory operand. -- ``q``: Print the 64-bit register name (e.g. ``rax``), if 64-bit registers are +- ``q``: Print the 64-bit register name (e.g., ``rax``), if 64-bit registers are available, otherwise the 32-bit register name; do nothing on a memory operand. - ``n``: Negate and print an unadorned integer, or, for operands other than an - immediate integer (e.g. a relocatable symbol expression), print a '-' before + immediate integer (e.g., a relocatable symbol expression), print a '-' before the operand. (The behavior for relocatable symbol expressions is a target-specific behavior for this typically target-independent modifier) - ``H``: Print a memory reference with additional offset +8. @@ -6883,7 +6883,7 @@ See :ref:`diexpression` for details. .. note:: ``DIExpression``\s are always printed and parsed inline; they can never be - referenced by an ID (e.g. ``!1``). + referenced by an ID (e.g., ``!1``). Some examples of expressions: @@ -8469,8 +8469,8 @@ that was typically cold and one allocating memory that was typically not cold. The format of the metadata describing a context specific profile (e.g. ``!1`` and ``!3`` above) requires a first operand that is a metadata node describing the context, followed by a list of string metadata tags describing -the profile behavior (e.g. ``cold`` and ``notcold``) above. The metadata nodes -describing the context (e.g. ``!2`` and ``!4`` above) are unique ids +the profile behavior (e.g., ``cold`` and ``notcold``) above. The metadata nodes +describing the context (e.g., ``!2`` and ``!4`` above) are unique ids corresponding to callsites, which can be matched to associated IR calls via :ref:`callsite metadata<md_callsite>`. In practice these ids are formed via a hash of the callsite's debug info, and the associated call may be in a @@ -8946,7 +8946,7 @@ in syntax by a caret ('``^``'). The summary is parsed into a bitcode output, along with the Module IR, via the "``llvm-as``" tool. Tools that parse the Module IR for the purposes -of optimization (e.g. "``clang -x ir``" and "``opt``"), will ignore the +of optimization (e.g., "``clang -x ir``" and "``opt``"), will ignore the summary entries (just as they currently ignore summary entries in a bitcode input file). @@ -9176,7 +9176,7 @@ The optional ``Refs`` field looks like: refs: ((Ref)[, (Ref)]*) where each ``Ref`` contains a reference to the summary id of the referenced -value (e.g. ``^1``). +value (e.g., ``^1``). .. _typeidinfo_summary: @@ -10385,7 +10385,7 @@ bit width of the result. Because LLVM integers use a two's complement representation, and the result is the same width as the operands, this instruction returns the correct result for both signed and unsigned integers. If a full product -(e.g. ``i32`` * ``i32`` -> ``i64``) is needed, the operands should be +(e.g., ``i32`` * ``i32`` -> ``i64``) is needed, the operands should be sign-extended or zero-extended as appropriate to the width of the full product. @@ -11378,7 +11378,7 @@ allocation on any convenient boundary compatible with the type. '``type``' may be any sized type. Structs containing scalable vectors cannot be used in allocas unless all -fields are the same scalable vector type (e.g. ``{<vscale x 2 x i32>, +fields are the same scalable vector type (e.g., ``{<vscale x 2 x i32>, <vscale x 2 x i32>}`` contains the same type while ``{<vscale x 2 x i32>, <vscale x 2 x i64>}`` doesn't). @@ -12766,7 +12766,7 @@ pointer then a truncation is done. If ``value`` is smaller than the size of a pointer then a zero extension is done. If they are the same size, nothing is done (*no-op cast*). The behavior is equivalent to a ``bitcast``, however, the resulting value is not -guaranteed to be dereferenceable (e.g. if the result type is a +guaranteed to be dereferenceable (e.g., if the result type is a :ref:`non-integral pointers <nointptrtype>`). Example: @@ -14697,7 +14697,7 @@ C++ object with a non-trivial destructor. ``llvm.seh.scope.begin`` is used to m the start of the region; it is always called with ``invoke``, with the unwind block being the desired unwind destination for any potentially-throwing instructions within the region. `llvm.seh.scope.end` is used to mark when the scope ends -and the EH cleanup is no longer required (e.g. because the destructor is being +and the EH cleanup is no longer required (e.g., because the destructor is being called). .. _int_read_register: @@ -14737,7 +14737,7 @@ return the current value of the register, where possible. The where possible. A call to '``llvm.read_volatile_register``' is assumed to have side-effects -and possibly return a different value each time (e.g. for a timer register). +and possibly return a different value each time (e.g., for a timer register). This is useful to implement named register global variables that need to always be mapped to a specific register, as is common practice on @@ -15008,9 +15008,9 @@ flushes the instruction cache. Semantics: """""""""" -On platforms with coherent instruction and data caches (e.g. x86), this +On platforms with coherent instruction and data caches (e.g., x86), this intrinsic is a nop. On platforms with non-coherent instruction and data -cache (e.g. ARM, MIPS), the intrinsic is lowered either to appropriate +cache (e.g., ARM, MIPS), the intrinsic is lowered either to appropriate instructions or a system call, if cache flushing requires special privileges. @@ -15462,7 +15462,7 @@ A call to '``llvm.call.preallocated.arg``' must have a call site ``preallocated`` attribute. The type of the ``preallocated`` attribute must match the type used by the ``preallocated`` attribute of the corresponding argument at the preallocated call. The type is used in the case that an -``llvm.call.preallocated.setup`` does not have a corresponding call (e.g. due +``llvm.call.preallocated.setup`` does not have a corresponding call (e.g., due to DCE), where otherwise we cannot know how large the arguments are. It is undefined behavior if this is called with a token from an @@ -16656,7 +16656,7 @@ for large input values. .. note:: Currently, the default lowering of this intrinsic relies on the ``sincospi[f|l]`` - functions being available in the target's runtime (e.g. libc). + functions being available in the target's runtime (e.g., libc). When specified with the fast-math-flag 'afn', the result may be approximated using a less accurate calculation. @@ -19719,7 +19719,7 @@ Arguments: """""""""" The integer operand is the loop trip count of the hardware-loop, and thus -not e.g. the loop back-edge taken count. +not e.g., the loop back-edge taken count. Semantics: """""""""" @@ -19758,7 +19758,7 @@ Arguments: """""""""" The integer operand is the loop trip count of the hardware-loop, and thus -not e.g. the loop back-edge taken count. +not e.g., the loop back-edge taken count. Semantics: """""""""" @@ -19794,7 +19794,7 @@ Arguments: """""""""" The integer operand is the loop trip count of the hardware-loop, and thus -not e.g. the loop back-edge taken count. +not e.g., the loop back-edge taken count. Semantics: """""""""" @@ -19832,7 +19832,7 @@ Arguments: """""""""" The integer operand is the loop trip count of the hardware-loop, and thus -not e.g. the loop back-edge taken count. +not e.g., the loop back-edge taken count. Semantics: """""""""" @@ -20768,7 +20768,7 @@ of the result's type, while maintaining the same element type. Semantics: """""""""" -Other than the reduction operator (e.g. add) the way in which the concatenated +Other than the reduction operator (e.g., add) the way in which the concatenated arguments is reduced is entirely unspecified. By their nature these intrinsics are not expected to be useful in isolation but instead implement the first phase of an overall reduction operation. @@ -24286,7 +24286,7 @@ The arguments are scalar types to accommodate scalable vector types, for which it is unknown what the type of the step vector needs to be that enumerate its lanes without overflow. -This mask ``%m`` can e.g. be used in masked load/store instructions. These +This mask ``%m`` can e.g., be used in masked load/store instructions. These intrinsics provide a hint to the backend. I.e., for a vector loop, the back-edge taken count of the original scalar loop is explicit as the second argument. @@ -27966,7 +27966,7 @@ The quiet comparison operation performed by if either argument is a SNAN. The signaling comparison operation performed by '``llvm.experimental.constrained.fcmps``' will raise an exception if either argument is a NAN (QNAN or SNAN). Such an exception -does not preclude a result being produced (e.g. exception might only +does not preclude a result being produced (e.g., exception might only set a flag), therefore the distinction between ordered and unordered comparisons is also relevant for the '``llvm.experimental.constrained.fcmps``' intrinsic. @@ -29983,7 +29983,7 @@ Semantics: On some platforms, the value returned by this intrinsic remains unchanged between loads in the same thread. On other platforms, it returns the same -global variable value, if any, e.g. ``@__stack_chk_guard``. +global variable value, if any, e.g., ``@__stack_chk_guard``. Currently some platforms have IR-level customized stack guard loading (e.g. X86 Linux) that is not handled by ``llvm.stackguard()``, while they should be |