Lines Matching +refs:is +refs:effective +refs:target +refs:keyword
12 This document is a reference manual for the LLVM assembly language. LLVM
13 is a Static Single Assignment (SSA) based representation that provides
15 representing 'all' high-level languages cleanly. It is the common code
22 The LLVM code representation is designed to be used in three different
38 the target of optimizations: for example, through pointer analysis, it
39 can be proven that a C automatic variable is never accessed outside of
48 It is important to note that this document describes 'well formed' LLVM
49 assembly language. There is a difference between what the parser accepts
50 and what is considered 'well formed'. For example, the following
51 instruction is syntactically okay, but not well formed:
59 verify that an LLVM module is well formed. This pass is automatically
77 ``%a.really.long.identifier``. The actual regular expression used is
80 characters may be escaped using ``"\xx"`` where ``xx`` is the ASCII
102 Here is an example of LLVM code to multiply the integer variable
129 #. Unnamed temporaries are created when the result of a computation is
134 entry basic block is not given a label name and all function parameters are
147 LLVM programs are composed of ``Module``'s, each of which is a
152 symbol table entries. Here is an example of the "hello world" module:
176 This example is made up of a :ref:`global variable <globalvars>` named
181 In general, a module is made up of a list of global values (where both
200 symbol is private to the module, all references can be updated. This
205 corresponds to the notion of the '``static``' keyword in C.
209 perspective, an ``available_externally`` global is equivalent to
212 global, which is known to be somewhere outside the module. Globals
214 will, and allow inlining and other optimizations. This linkage type is
225 know if this definition of the function is the definitive definition
232 not be discarded. This is used for globals that are declared "weak"
235 "``common``" linkage is most similar to "``weak``" linkage, but they
250 together. This is the LLVM, typesafe, equivalent of having the
260 symbol is weak until linked, if not linked, the symbol becomes null
271 If none of the above identifiers are used, the global is externally
275 It is illegal for a global variable or function *declaration* to have any
286 caller/callee must match, or the behavior of the program is undefined.
292 is specified) matches the target C calling conventions. This calling
299 allows the target to use whatever tricks it wants to produce fast
300 code for the target, without having to conform to an externally
302 be optimized when this, the tailcc, the GHC or the HiPE convention is
308 efficient as possible under the assumption that the call is not
355 This is a special convention that supports patching an arbitrary code
375 The idea behind this convention is to support calls to runtime functions
376 that have a hot path and a cold path. The hot path is usually a small piece
380 `PreserveMost` calling convention is very similar to the `cold` calling
382 different types of function calls. `coldcc` is for function calls that are
390 the ObjectiveC runtime, it is not limited to this runtime and might be used
392 supports X86-64, but the intention is to support more architectures in the
409 The idea behind this convention is to support calls to runtime functions
418 block that is run at the first time. The entry and exit blocks can access
435 "``swiftcc``" - This calling convention is used for Swift language.
441 tail call optimized. This calling convention is equivalent to fastcc,
444 the GHC or the HiPE convention is used. <CodeGenerator.html#id80>`_ This
448 This calling convention is used for the Control Flow Guard check function,
450 target is a valid function address. The check function has no return value,
451 but it will trigger an OS-level error if the address is not a valid target.
453 containing the target address are architecture-specific.
455 - On X86 the target address is passed in ECX.
456 - On ARM the target address is passed in R0.
457 - On AArch64 the target address is passed in X15.
460 target-specific calling conventions to be used. Target specific
464 support Pascal conventions or any other well-known target-independent
477 means that the declaration is visible to other modules and, in
479 On Darwin, default visibility means that the declaration is visible
491 defining module will bind to the local symbol. That is, the symbol
507 a global pointer to a pointer that is set up by the DLL exporting the
508 symbol. On Microsoft Windows targets, the pointer name is formed by
513 Microsoft Windows targets, the pointer name is formed by combining
516 it is externally referenced and must refrain from deleting the symbol.
535 If no explicit model is given, the "general dynamic" model is used.
540 be used. The target may choose a different TLS model if the specified
541 model is not supported, or if a better choice of model can be made.
544 the alias is accessed. It will not have any effect in the aliasee.
556 symbol is assumed to be ``dso_preemptable``.
565 be generated even if the definition is not within this compilation unit.
575 to forward declare a type that is not yet available.
577 An example of an identified structure specification is:
597 representation; that is, the integral representation may be target dependent or
622 is a mismatch between the explicit or inferred section information for the
623 variable declaration and its definition the resulting behavior is undefined.
629 initialization cannot be marked ``constant`` as there is a store to the
633 constant, even if the final definition of the global is not. This
646 that the address is not significant, only the content. Constants marked
650 whose address is significant.
652 If the ``local_unnamed_addr`` attribute is given, the address is known to
655 A global variable may be declared to reside in a target-specific
657 may affect how optimizations are performed and/or what target
659 is zero. The address space qualifier must precede any other attributes.
662 target supports it, it will emit globals to the section specified.
663 Additionally, the global can placed in a comdat if the target has the necessary
667 information is retained in LLVM IR for targets that make use of this
668 information. Attaching section information to an external declaration is an
669 assertion that its definition is located in the specified section. If the
670 definition is located in a different section, the behavior is undefined.
674 initial values before the start of the global initializer. This is
681 power of 2. If not present, or if the alignment is set to zero, the
682 alignment of the global is set by the target to whatever it feels
683 convenient. If an explicit alignment is specified, the global is forced
689 iteration. The maximum alignment is ``1 << 29``.
707 structs or arrays because their size is unknown at compile time.
744 LLVM function definitions consist of the "``define``" keyword, an
761 LLVM function declarations consist of the "``declare``" keyword, an
775 function return). If an explicit label name is not provided, a block is assigned
780 numeric label is explicitly specified, it must match the numeric label that
783 The first basic block in a function is special in two ways: it is
784 immediately executed on entrance to the function, and it is not allowed
790 target supports it, it will emit functions to the section specified.
794 or if the alignment is set to zero, the alignment of the function is set
795 by the target to whatever it feels convenient. If an explicit alignment
796 is specified, the function is forced to have at least that much
799 If the ``unnamed_addr`` attribute is given, the address is known to not
802 If the ``local_unnamed_addr`` attribute is given, the address is known to
805 If an explicit address space is not given, it will default to the program
817 The argument list is a comma separated sequence of arguments where each
818 argument is of the following form:
833 Aliases have a name and an aliasee that is either a global value or a
847 might not correctly handle dropping a weak symbol that is aliased.
853 If the ``local_unnamed_addr`` attribute is given, the address is known to
860 time. Since it is just a name, no relocations can be used.
867 would require a relocation, which is not possible.
877 IFuncs have a name and a resolver that is a function called by dynamic linker
910 The linker may choose any COMDAT key, the choice is arbitrary.
925 Here is an example of a COMDAT group where a function will only be selected if
926 the COMDAT key's section is the largest:
937 As a syntactic sugar the ``$name`` can be omitted if the name is the same as
949 ``IMAGE_COMDAT_SELECT_ASSOCIATIVE`` which is associated with the first COMDAT
972 with the same name. This is necessary because both globals belong to different
978 COMDAT IR. This arises when the code generator is configured to emit globals
980 is supplied to `llc`).
987 Named metadata is a collection of metadata. :ref:`Metadata
1034 value should be zero-extended to the extent required by the target's
1038 value should be sign-extended to the extent required by the target's
1039 ABI (which is usually 32-bits) by the caller (for a parameter) or
1043 in a special target-dependent fashion while emitting code for
1046 two different kinds of registers). Use of this attribute is
1047 target-specific.
1051 the pointee is made between the caller and the callee, so the callee
1052 is unable to modify the value in the caller. This attribute is only
1053 valid on LLVM pointer arguments. It is generally used to pass
1054 structs and arrays by value, but is also valid on pointers to
1055 scalars. The copy is considered to belong to the caller not the
1057 ``byval`` parameters). This is not a valid attribute for return
1066 site. If the alignment is not specified, then the code generator
1067 makes a target-specific assumption.
1074 memory type of an argument. This is similar to ``byval``, but does
1075 not imply a copy is made anywhere, or that the argument is passed
1076 on the stack. This implies the pointer is dereferenceable up to
1079 It is not generally permissible to introduce a write to an
1083 This is not a valid attribute for return values.
1087 ``byval``. If the alignment is not specified, then the code generator
1088 makes a target-specific assumption.
1090 This is intended for representing ABI constraints, and is not
1099 is only valid on LLVM pointer arguments. The argument must be the value
1103 calls, although it is ignored during codegen.
1115 site. If the alignment is not specified, then the code generator
1116 makes a target-specific assumption.
1126 inalloca keyword. Only the last argument may have the ``inalloca``
1127 attribute, and that argument is guaranteed to be passed in memory.
1137 When the call site is reached, the argument allocation must have
1138 been the most recent stack allocation that is still live, or the
1139 behavior is undefined. It is possible to allocate additional stack
1149 structure that is the return value of the function in the source
1152 to trap and to be properly aligned. This is not a valid attribute
1164 specified alignment, behavior is undefined. ``align 1`` has no effect on
1184 Note that this definition of ``noalias`` is intentionally similar
1187 For function return values, C99's ``restrict`` is not meaningful,
1188 while LLVM's ``noalias`` is. Furthermore, the semantics of the ``noalias``
1197 pointer that outlive the callee itself. This is not a valid
1202 This indicates that callee does not free the pointer argument. This is not
1209 :ref:`trampoline intrinsics <int_trampoline>`. This is not a valid
1214 value. This is a hint to the optimizer and code generator used when
1216 and omission of register saves and restores in some cases; it is not
1219 :ref:`bitcast instruction <i_bitcast>`. This is not a valid attribute for
1223 This indicates that the parameter or return pointer is not null. This
1224 attribute may only be applied to pointer typed parameters. This is not
1225 checked or enforced by LLVM; if the parameter or return pointer is null,
1226 the behavior is undefined.
1229 This indicates that the parameter or return pointer is dereferenceable. This
1231 is dereferenceable can be loaded from speculatively without a risk of
1233 in parentheses. It is legal for the number of bytes to be less than the
1237 ``addrspace(0)`` (which is the default address space), except if the
1238 ``null_pointer_is_valid`` function attribute is present.
1246 a pointer is exactly one of ``dereferenceable(<n>)`` or ``null``,
1248 implies that a pointer is at least one of ``dereferenceable(<n>)``
1254 This indicates that the parameter is the self/context parameter. This is not
1259 This attribute is motivated to model and optimize Swift error handling. It
1265 a ``swifterror`` argument. This is not a valid attribute for return values
1272 on a parameter is not ABI-compatible with one which does not.
1279 This indicates the parameter is required to be an immediate
1281 constant. Undef or constant expressions are not valid. This is
1287 representation contains any undefined or poison bits, the behavior is
1296 Each function may specify a garbage collector strategy name, which is simply a
1307 garbage collector, this functionality is restricted to generating machine code
1315 Prefix data is data associated with a function which the code
1317 The purpose of this feature is to allow frontends to associate
1340 Prefix data is laid out as if it were an initializer for a global variable
1342 beginning of the prefix data is aligned. This means that if the size
1343 of the prefix data is not a multiple of the alignment size, the
1345 function's entrypoint is desired, padding must be added to the prefix
1364 module's target, which transfer control to the point immediately succeeding
1368 makes the format of the prologue data highly target dependent.
1370 A trivial example of valid prologue data for the x86 architecture is ``i8 144``,
1410 An attribute group is a module-level object. To use an attribute group, an
1415 Here is an example of attribute groups for a function that should always be
1458 parameter numbers; if one argument is provided, then it's assumed that at
1471 uses the ``nobuiltin`` attribute. This is only valid at call sites for
1475 This attribute indicates that this function is rarely called. When
1487 For example, the intrinsic ``llvm.nvvm.barrier0`` is ``convergent``, so
1493 function. This is particularly useful on indirect calls; without this we
1494 may treat such calls as though the target is non-convergent.
1502 is not accessible by the module being compiled. This is a weaker form
1504 behavior is undefined.
1506 This attribute indicates that the function may only access memory that is
1507 either not accessible by the module being compiled, or is pointed to
1508 by its pointer arguments. This is a weaker form of ``argmemonly``. If the
1509 function reads or writes other memory, the behavior is undefined.
1512 inlining this function is desirable (such as the "inline" keyword in
1513 C/C++). It is just a hint; it imposes no requirements on the
1532 When this attribute is set to true, the inliner discards source locations
1539 When this attribute is set to true, the jump tables and lookup tables that
1542 This indicates that the callee function at a call site is not recognized as
1545 the call site uses the ``builtin`` attribute. This is valid at call sites
1554 be an inlining candidate, provided that the call is not
1557 call is dead after inlining.
1563 dereferenceable after the call (the capturing condition is necessary in
1583 startup time if the function is not called during program startup.
1586 red zone, even if the target-specific ABI normally permits it.
1590 target-specific ABI normally permits it.
1595 functions may still raise an exception, i.a., ``nounwind`` is not implied.
1604 Annotated functions may still raise an exception, i.a., ``nounwind`` is not implied.
1606 to a point in the call stack, the behavior is undefined.
1610 Synchronization is considered possible in the presence of `atomic` accesses
1616 the behavior is undefined.
1620 behavior is undefined. However, functions marked nounwind may still
1625 If ``null_pointer_is_valid`` is set, then the ``null`` address
1626 in address-space 0 is considered to be a valid address for memory loads and
1640 attribute; this attribute is also incompatible
1644 the function as well, so the function is never inlined into any caller.
1657 for which there currently is one legal possibility:
1660 function is intended to support patching a function prologue to
1671 ``"prologue-short-redirect"`` is currently only supported on
1684 If a function that has a ``"probe-stack"`` attribute is inlined into
1687 function that has a ``"probe-stack"`` attribute is inlined into a
1707 has other side-effects, the behavior is undefined. If a function reads from
1708 or writes to a readnone pointer argument, the behavior is undefined.
1726 has other side-effects, the behavior is undefined. If a function writes to
1727 a readonly pointer argument, the behavior is undefined.
1734 is 4096 by default.
1736 If a function that has a ``"stack-probe-size"`` attribute is inlined into
1739 numeric value. If a function that has a ``"stack-probe-size"`` attribute is
1754 has other side-effects, the behavior is undefined. If a function reads
1755 from a writeonly pointer argument, the behavior is undefined.
1767 arguments, or has other side-effects, the behavior is undefined.
1770 ``setjmp`` is an example of such a function. The compiler disables
1776 protection is enabled for this function.
1778 If a function that has a ``safestack`` attribute is inlined into a
1804 Speculative Load Hardening is a best-effort mitigation against
1807 is taken or not. Typically vulnerabilities enabling such attacks are
1809 mitigate against miss-speculation of branch target, classified as
1812 When inlining, the attribute is sticky. Inlining a function that carries
1813 this attribute will cause the caller to gain the attribute. This is intended
1820 Note that ``speculatable`` is not enough to conclude that along any
1822 externally observable. This attribute is only valid on functions
1823 and declarations, not on individual call sites. If a function is
1826 if the call site is dead code.
1830 smashing protector. It is in the form of a "canary" --- a random value
1833 heuristic is used to determine if a function needs stack protectors
1844 If a function that has an ``ssp`` attribute is inlined into a
1863 If a function that has an ``sspreq`` attribute is inlined into a
1891 If a function that has an ``sspstrong`` attribute is inlined into a
1904 assumed for the default floating-point environment. This is a
1910 bitcode, if the second value is omitted, both input and output
1913 If this is attribute is not specified, the default is
1916 If the output mode is ``"preserve-sign"``, or ``"positive-zero"``,
1918 operations. It is not mandated that flushing to zero occurs, but if
1919 a denormal output is flushed to zero, it must respect the sign
1922 this does not make any attempt to ensure the mode is
1923 consistent. User or platform code is expected to set the floating
1926 If the input mode is ``"preserve-sign"``, or ``"positive-zero"``, a
1937 attempt is made to diagnose unsupported uses. Currently this
1938 attribute is respected by the AMDGPU and NVPTX backends.
1943 optimization purposes. The caller is expected to cast the thunk prototype to
1944 match the thunk target prototype.
1948 show that no exceptions passes by it. This is normally the case for
1955 is target independent and currently appertains to a function or function
1960 function has not changed between the function prolog and epilog. It is
1963 This attribute indicates that the function is required to return, unwind,
1966 attribute is intended to model the requirements of the first section of
1971 function does not satisfy this contract, the behavior is undefined. This
1987 not imply preference (it is logically a set). The compiler is free
1990 The syntax for the mangled names is as follows:::
1997 vectors. The shape of the vector function is described by the
1999 token. The standard name of the vector function is
2002 that a custom name is provided in addition to the standard one
2005 present in the IR Module. The signature of the vector variant is
2007 specifications of the target. For Arm and X86, the VFABI can be
2016 the target ISAs (for example, some of the mappings stored in the
2047 This attribute is required on calls to ``llvm.call.preallocated.arg``
2068 ``invoke`` s). In a way they are like metadata, but dropping them is
2090 long as the behavior of an operand bundle is describable within these
2095 ways before control is transferred to the callee or invokee.
2097 effect on the heap on entry and exit (even if the call target is
2116 bundle attached to a call site. Exact details of deoptimization is
2162 It is the frontend's responsibility to structure or encode the
2164 caller's deoptimization state to the callee's deoptimization state is
2175 is within a particular funclet. There can be at most one
2181 it is undefined behavior to execute a ``call`` or ``invoke`` which:
2183 * does not have a ``"funclet"`` bundle and is not a ``call`` to a nounwind
2185 * has a ``"funclet"`` bundle whose operand is not the most-recently-entered
2189 executing a ``call`` or ``invoke`` with a ``"funclet"`` bundle is undefined behavior.
2205 the appropriate GC_TRANSITION nodes in the selection DAG. It is assumed
2226 * The tag of the operand bundle is usually the name of attribute that can be
2229 * The first argument if present is the value for which the attribute hold.
2230 * The second argument if present is an argument of the attribute.
2232 If there are no arguments the attribute is a property of the call location.
2251 call location is cold and that ``%val`` may not be null.
2254 provided guarantees are are violated at runtime the behavior is undefined.
2277 of the call argument memory from the call site. This is necessary to pass
2278 non-trivially copyable objects by value in a way that is compatible with MSVC
2280 attached to a call site and it must have exactly one bundle operand, which is
2302 A "gc-live" operand bundle is only valid on a :ref:`gc.statepoint <gc_statepoint>`
2318 in the ``.ll`` file if desired. The syntax is very simple:
2326 characters. The escape sequence used is simply "\\xx" where "xx" is the
2330 (unless it is disabled), even when emitting a ``.s`` file.
2337 A module may specify a target specific data layout string that specifies
2338 how data is to be laid out in memory. The syntax for the data layout is
2343 target datalayout = "layout specification"
2352 Specifies that the target lays out data in big-endian form. That is,
2356 Specifies that the target lays out data in little-endian form. That
2357 is, the bits with the least significance have the lowest address
2361 promotion of stack variables is limited to the natural stack
2387 ``<idx>`` is a size of index that used for address calculation. If not
2388 specified, the default index size is equal to the pointer size. All sizes
2389 are in bits. The address space, ``n``, is optional, and if not specified,
2400 ``<size>``. Only values of ``<size>`` that are supported by the target
2410 * ``i``: The alignment of function pointers is independent of the alignment
2411 of functions, and is a multiple of ``<abi>``.
2412 * ``n``: The alignment of function pointers is a multiple of the explicit
2413 alignment specified on the function, and is a multiple of ``<abi>``.
2427 ``@N`` where N is the number of bytes used to pass parameters. C++ symbols
2433 This specifies a set of native integer widths for the target CPU in
2444 ``<pref>`` alignment is optional. If omitted, the preceding ``:``
2447 When constructing the data layout for a given target, LLVM starts with a
2449 the specifications in the ``datalayout`` keyword. The default
2456 - ``S0`` - natural stack alignment is unspecified
2457 - ``i1:8:8`` - i1 is 8-bit (byte) aligned
2458 - ``i8:8:8`` - i8 is 8-bit (byte) aligned
2459 - ``i16:16:16`` - i16 is 16-bit aligned
2460 - ``i32:32:32`` - i32 is 32-bit aligned
2463 - ``f16:16:16`` - half is 16-bit aligned
2464 - ``f32:32:32`` - float is 32-bit aligned
2465 - ``f64:64:64`` - double is 64-bit aligned
2466 - ``f128:128:128`` - quad is 128-bit aligned
2467 - ``v64:64:64`` - 64-bit vector is 64-bit aligned
2468 - ``v128:128:128`` - 128-bit vector is 128-bit aligned
2471 When LLVM is determining the alignment for a given type, it uses the
2474 #. If the type sought is an exact match for one of the specifications,
2475 that specification is used.
2476 #. If no match is found, and the type sought is an integer type, then
2477 the smallest integer type that is larger than the bitwidth of the
2478 sought type is used. If none of the specifications are larger than
2479 the bitwidth then the largest integer type is used. For example,
2483 #. If no match is found, and the type sought is a vector type, then the
2484 largest vector type that is smaller than the sought vector type will
2489 Notably, this is not a specification from the frontend of what alignment
2492 Instead, if specified, the target data layout is required to match what
2493 the ultimate *code generator* expects. This string is used by the
2495 what the ultimate code generator uses. There is no way to generate IR
2496 that does not embed this target-specific detail into the IR. If you
2499 accordingly and introduce target specificity into the IR with respect to
2507 A module may specify a target triple string that describes the target
2508 host. The syntax for the target triple is simply:
2512 target triple = "x86_64-apple-macosx10.7.0"
2514 The *target triple* string consists of a series of identifiers delimited
2522 This information is passed along to the backend so that it generates
2532 an address range of the memory access, otherwise the behavior is
2536 - A pointer value is associated with the addresses associated with any
2537 value it is *based* on.
2538 - An address of a global variable is associated with the address range
2540 - The result value of an allocation instruction is associated with the
2542 - A null pointer in the default address-space is associated with no
2544 - An :ref:`undef value <undefvalues>` in *any* address-space is
2552 A pointer value is *based* on another pointer value according to the
2555 - A pointer value formed from a scalar ``getelementptr`` operation is *based* on
2558 is *based* on the pointer in lane *l* of the vector-of-pointers-typed operand
2560 - The result value of a ``bitcast`` is *based* on the operand of the
2562 - A pointer value formed by an ``inttoptr`` is *based* on all pointer
2565 - The "*based* on" relationship is transitive.
2567 Note that this definition of *"based"* is intentionally similar to the
2568 definition of *"based"* in C99, though it is slightly weaker.
2577 ``-fstrict-aliasing``, is not applicable to general unadorned LLVM IR.
2592 operations relative to non-volatile operations. This is not Java's
2595 A volatile load or store may have additional target-specific semantics.
2597 can read and/or modify state which is not accessible via a regular load
2615 Likewise, the backend should never split or merge target-legal volatile
2637 in their presence. This model is inspired by the C++0x memory model.
2659 initializer which is atomic and happens before any other read or write
2669 Given that definition, R\ :sub:`byte` is defined as follows:
2671 - If R is volatile, the result is target-dependent. (Volatile is
2676 - Otherwise, if there is no write to the same byte that happens before
2680 - Otherwise, if R is atomic, and all the writes R\ :sub:`byte` may
2683 constraints on how the choice is made.
2694 is required for single-threaded execution: introducing a store to a byte
2695 which might not otherwise be stored is not allowed in general.
2721 The set of values that can be read is governed by the happens-before
2723 it. This is intended to provide a guarantee strong enough to model
2725 specified for read-modify-write operations; it is not strong enough
2728 In addition to the guarantees of ``unordered``, there is a single
2731 happens-before order. There is no guarantee that the modification
2740 stronger) operations on the same address. If an address is written
2748 This is intended to model C++'s ``memory_order_acquire``.
2751 writes a value which is subsequently read by an ``acquire``
2762 writes), there is a global total order on all
2763 sequentially-consistent operations on all addresses, which is
2772 If an atomic operation is marked ``syncscope("singlethread")``, it only
2776 If an atomic operation is marked ``syncscope("<target-scope>")``, where
2777 ``<target-scope>`` is a target specific synchronization scope, then it is target
2781 Otherwise, an atomic operation that is not marked ``syncscope("singlethread")``
2782 or ``syncscope("<target-scope>")`` *synchronizes with* and participates in the
2784 ``syncscope("singlethread")`` or ``syncscope("<target-scope>")``.
2793 rounding mode. No floating-point exception state is maintained in this
2794 environment. Therefore, there is no attempt to create or preserve invalid
2797 The benefit of this exception-free assumption is that floating-point
2818 NaN. If an argument is a nan, or the result would be a nan, it produces
2823 +/-Inf. If an argument is +/-Inf, or the result would be +/-Inf, it
2829 is poison and/or guaranteed to not exist in the operation.
2859 order to be recreated. ``<order-indexes>`` is a comma-separated list of
2861 value's use-list is immediately sorted by these indexes.
2904 The *source filename* string is set to the original module identifier,
2906 source through the clang front end, for example. It is then preserved through
2909 This is currently necessary to generate a consistent unique global
2913 The syntax for the source file name is simply:
2924 The LLVM type system is one of the most important features of the
2960 type is a void type or first class type --- except for :ref:`label <t_label>`
2969 ...where '``<parameter list>``' is a comma-separated list of type
2973 handling intrinsic <int_varargs>` functions. '``<returntype>``' is any type
2983 …pointer <t_pointer>` to ``i8`` (char in C), which returns an integer. This is the signature for ``…
3011 The integer type is a very simple type that simply specifies an
3021 The number of bits the integer will occupy is specified by the ``N``
3100 The pointer type is used to specify memory locations. Pointers are
3105 address space is number zero. The semantics of non-zero address spaces
3106 are target-specific.
3134 A vector type is a simple derived type that represents a vector of
3139 vector length is unknown at compile time. Vector types are considered
3149 The number of elements is a constant integer value larger than 0;
3152 elements is a constant multiple (called vscale) of the specified number
3153 of elements; vscale is a positive integer that is unknown at compile time
3155 time. The size of a specific scalable vector type is thus constant within
3194 The token type is used when a value is associated with an instruction
3196 As such, it is not appropriate to have a :ref:`phi <i_phi>` or
3240 The array type is a very simple derived type that arranges elements
3250 The number of elements is a constant integer value; ``elementtype`` may
3273 There is no restriction on indexing beyond the end of the array implied
3288 The structure type is used to represent a collection of data members
3298 the alignment of the struct is one byte, and that there is no padding
3300 is inserted as defined by the DataLayout string in the module, which is
3304 is defined inline with other types (e.g. ``{i32, i32}*``) whereas
3307 or opaque since there is no way to write one. Identified types can be
3322 …at, i32 (i32) * }`` | A pair, where the first element is a ``float`` and the second element is a…
3374 assembler accepts 1.25 but rejects 1.3 because 1.3 is a repeating
3378 The identifier '``null``' is recognized as a null pointer constant
3381 The identifier '``none``' is recognized as an empty token constant
3384 The one non-intuitive notation for constants is the hexadecimal form of
3386 '``double 0x432ff973cafa8000``' is equivalent to (but harder to read
3389 disassembler) is when a floating-point constant must be emitted but it
3399 precision respectively. Hexadecimal format is always used for long double, and
3400 there are three forms of long double. The 80-bit format used by x86 is
3402 used by PowerPC (two adjacent doubles) is represented by ``0xM`` followed by 32
3403 hexadecimal digits. The IEEE 128-bit format is represented by ``0xL`` followed
3405 double format on your target. The IEEE 16-bit format (half precision) is
3407 format is represented by ``0xR`` followed by 4 hexadecimal digits. All
3424 "``{ i32 4, float 17.0, i32* @G }``", where "``@G``" is declared as
3447 :ref:`aggregate <t_aggregate>` types. This is often used to avoid
3449 is always exactly equivalent to using explicit zero initializers.
3451 A metadata node is a constant tuple without types. For example:
3455 the instruction stream, metadata is a place to attach additional
3464 the :ref:`identifier for the global <identifiers>` is used and always have
3465 :ref:`pointer <t_pointer>` type. For example, the following is a legal LLVM
3479 The string '``undef``' can be used anywhere a constant is expected, and
3482 or '``void``') and be used anywhere a constant is permitted.
3485 the program is well defined no matter what value is used. This gives the
3499 This is safe because all of the output bits are affected by the undef
3519 the corresponding bit from the '``undef``' is. As such, it is unsafe to
3520 optimize or assume that the result of the '``and``' is '``undef``'.
3521 However, it is safe to assume that all bits of the '``undef``' could be
3522 0, and optimize the '``and``' to 0. Likewise, it is safe to assume that
3544 cleared low bit. However, in the ``%C`` example, the optimizer is
3569 C semantics) where they assume that "``X^X``" is always zero, even if
3570 ``X`` is undefined. This isn't true for a number of reasons, but the
3571 short answer is that an '``undef``' "variable" can arbitrarily change
3572 its value over its "live range". This is true because the variable
3573 doesn't actually *have a live range*. Instead, the value is logically
3575 the value is not necessarily consistent over time. In fact, ``%A`` and
3591 and *undefined behavior*. An undefined value (like '``undef``') is
3594 could be zero, and zero divided by any value is zero.
3596 assumption: because the ``undef`` is allowed to be an arbitrary value,
3612 we can assume that the value is overwritten with bits that happen to
3617 Branching on an undefined value is undefined behavior.
3621 it is undefined behavior.
3632 %X = load i8* %ptr ; %X is undef
3643 This is also consistent with the behavior of MemorySanitizer.
3651 is only valid if in all executions where the branch condition has at
3652 least one undefined bit, the same branch condition is evaluated in the
3660 A poison value is a result of an erroneous operation.
3664 The string '``poison``' can be used anywhere a constant is expected, and
3668 Poison value behavior is defined in terms of value *dependence*:
3693 multiple successors and the instruction is always executed when
3695 when control is transferred to another.
3700 - Dependence is transitive.
3711 This means that immediate undefined behavior occurs if a poison value is
3713 behavior. Notably this includes (but is not limited to):
3759 Given a program execution, a value is *well defined* if the value does not
3760 have an undef bit and is not poison in the execution.
3761 An aggregate value or vector is well defined if its elements are well defined.
3765 A constant of a :ref:`single value <t_single_value>`, non-vector type is well
3766 defined if it is neither '``undef``' constant nor '``poison``' constant.
3767 The result of :ref:`freeze instruction <i_freeze>` is well defined regardless
3779 Taking the address of the entry block is illegal.
3784 results in undefined behavior --- though, again, comparison against null is ok,
3785 and no label is equal to the null pointer. This may be passed around as an
3788 long as the original value is reconstituted before the ``indirectbr`` or
3792 as the operand to an inline assembly, but that is target specific.
3801 A '``dso_local_equivalent``' constant represents a function which is
3802 functionally equivalent to a given function, but is always defined in the
3804 function. The resulting pointer is permitted, but not required, to be different
3808 The target function may not have ``extern_weak`` linkage.
3812 - If the function has local linkage, hidden visibility, or is
3817 a function or a stub for it, depending on if the function is defined within the
3818 linkage unit; LLVM will use this when available. (This is commonly called a
3821 This can be used wherever a ``dso_local`` instance of a function is needed without
3823 this can be used is for static offset calculations between a function and some other
3824 ``dso_local`` symbol. This is especially useful for the Relative VTables C++ ABI,
3829 This is currently only supported for ELF binary formats.
3840 The following is the syntax for constant expressions:
3861 value won't fit in the integer type, the result is a
3868 value won't fit in the integer type, the result is a
3884 This one is *really* dangerous!
3915 constants. The index list is interpreted in a similar manner as
3920 The index list is interpreted in a similar manner as indices in a
3949 be used, where ``MODIFIER`` is a target-specific annotation for how to print the
3955 resulting assembly string is parsed by LLVM's integrated assembler unless it is
3962 This substitution is useful when declaring a local label. Many standard
3965 during assembly. This is used to implement `GCC's %= special format
3967 - ``${:comment}``: Expands to the comment character of the current target's
3968 assembly dialect. This is usually ``#``, but many targets use other strings,
3972 Typically the prefix is ``L``, but targets may use other strings. ``.L`` is
3975 LLVM's support for inline asm is modeled closely on the requirements of Clang's
3979 described here is *not* the same as the syntax accepted by GCC and Clang, and,
3980 while most constraint letters are passed through as-is by Clang, some get
3984 An example inline assembler expression is:
3999 marked as having side effects. This is done through the use of the
4000 '``sideeffect``' keyword, like so:
4007 the stack is aligned in some way, such as calls or SSE instructions on
4011 prologue if the '``alignstack``' keyword is present:
4018 assumed dialect is ATT. When the '``inteldialect``' keyword is present,
4019 the inline asm is using the Intel dialect. Currently, ATT and Intel are
4020 the only supported dialects. An example is:
4026 If multiple keywords appear the '``sideeffect``' keyword must come
4027 first, the '``alignstack``' keyword second and the '``inteldialect``'
4028 keyword last.
4033 The constraint list is a comma-separated string, each element containing one or
4048 - Register constraint. This is either a register class, or a fixed physical
4051 - Memory constraint. This kind of constraint is for use with an instruction
4053 modes used by the target.
4054 - Immediate value constraint. This kind of constraint is for an integer or other
4056 various target-specific constraints allow the selection of a value in the
4068 Normally, it is expected that no output locations are written to by the assembly
4070 the same register to an output and an input. If this is not safe (e.g. if the
4073 modifier must be used (e.g. "``=&r``") to specify that the output is an
4082 constraint will consume one argument from the call instruction. It is not
4084 that input is tied to an output). Note also that multiple inputs may all be
4091 take up a position in the asm template numbering as is usual -- they will simply
4097 It is permitted to tie an input to an "early-clobber" output. In that case, no
4104 There is also an "interesting" feature which deserves a bit of explanation: if a
4105 register class constraint allocates a register which is too small for the value
4109 However, this feature is often not as useful as you might think.
4113 instructions, this is not an appropriate way to support them. (e.g. the 32-bit
4124 despite existing only for use with this feature, is not really a good idea to
4135 rather than producing a return value. An indirect output constraint is an
4136 "output" only in that the asm is expected to write to the contents of the input
4139 This is most typically used for memory constraint, e.g. "``=*m``", to pass the
4142 It is also possible to use an indirect *register* constraint, but only on output
4154 A clobber constraint is indicated by a "``~``" prefix. A clobber does not
4157 constraints, e.g. "``~{eax}``". The one exception is that a clobber string of
4163 constraints is not legal.
4170 A Constraint Code is either a single letter (e.g. "``r``"), a "``^``" character
4178 it up to LLVM to choose which one to use. This is included mainly for
4186 choice of constraint is made independently for each constraint in the
4195 ``"rm|r,ri|rm"``. This indicates that if operand 0 is ``r`` or ``m``, then
4196 operand 1 may be one of ``r`` or ``i``. If operand 0 is ``r``, then operand 1
4199 However, the use of either of the alternatives features is *NOT* recommended, as
4200 LLVM is not able to make an intelligent choice about which one to use. (At the
4201 point it currently needs to choose, not enough information is available to do so
4215 GCC. LLVM's support is often implemented on an 'as-needed' basis, to support C
4221 - ``r``: A register in the target's general purpose register class.
4222 - ``m``: A memory address operand. It is target-specific what addressing modes
4224 or register + immediate offset (of some target-specific size).
4225 - ``i``: An integer constant (of target-specific width). Allows either a simple
4237 Other constraints are target-specific:
4244 - ``J``: An immediate integer that, when negated, is valid for an ``ADD`` or
4246 - ``K``: An immediate integer that is valid for the 'bitmask immediate 32' of a
4248 - ``L``: An immediate integer that is valid for the 'bitmask immediate 64' of a
4251 32-bit register. This is a superset of ``K``: in addition to the bitmask
4255 64-bit register. This is a superset of ``L``.
4292 - ``K``: An immediate integer whose bitwise inverse is valid for a
4295 - ``L``: An immediate integer whose negation is valid for a data-processing
4320 - ``M``: An immediate integer which is a multiple of 4 between 0 and 1020.
4322 - ``O``: An immediate integer which is a multiple of 4 between -508 and 508.
4362 (``W0-W31``). In the case of MSA registers, it is recommended to use the ``w``
4386 - ``N``: An immediate integer that is an exact power of 2.
4388 - ``P``: An immediate integer constant whose negation is a signed 16-bit
4393 - ``b``: A 32 or 64-bit integer register, excluding ``R0`` (that is:
4461 ``l`` integer register. On X86-32, this is the ``a``, ``b``, ``c``, and ``d``
4462 registers, and on X86-64, it is all of the integer registers.
4464 ``h`` integer register. This is the ``a``, ``b``, ``c``, and ``d`` registers.
4469 - ``y``: A 64-bit MMX register, if MMX is enabled.
4470 - ``x``: If SSE is enabled: a 32 or 64-bit scalar operand, or 128-bit vector
4471 operand in a SSE register. If AVX is also enabled, can also be a 256-bit
4472 vector operand in an AVX register. If AVX-512 is also enabled, can also be a
4474 - ``Y``: The same as ``x``, if *SSE2* is enabled, otherwise an error.
4477 is not recommended to use this constraint, as in 64-bit mode, the 64-bit
4496 GCC. LLVM's support is often implemented on an 'as-needed' basis, to support C
4503 the target-specific immediate punctuation (e.g. no ``$`` prefix).
4505 target-specific immediate punctuation (e.g. no ``$`` prefix).
4506 - ``l``: Print as an unadorned label, without the target-specific label
4513 - ``x``: Print a GPR register with a ``x*`` name. (this is the default, anyhow).
4540 ``H`` is equivalent to ``Q``, and on little-endian system, ``H`` is equivalent
4556 .. FIXME: why is it restricted to consecutive ones? And there's
4557 nothing that ensures that happens, is there?
4559 - ``I``: Print the letter 'i' if the operand is an integer constant, otherwise
4584 second word of a double-word memory operand. (On a big-endian system, ``D`` is
4585 equivalent to ``L``, and on little-endian system, ``D`` is equivalent to
4600 .. FIXME: why is it restricted to consecutive ones? And there's
4601 nothing that ensures that happens, is there?
4603 - ``I``: Print the letter 'i' if the operand is an integer constant, otherwise
4607 - ``U``: Prints 'u' if the memory operand is an update form, and nothing
4610 - ``X``: Prints 'x' if the memory operand is an indexed form. (NOTE: LLVM does
4615 - ``i``: Print the letter 'i' if the operand is not a register, otherwise print
4627 target-independent modifiers.
4631 - ``c``: Print an unadorned integer or symbol name. (The latter is
4632 target-specific behavior for this typically target-independent modifier).
4646 the operand. (The behavior for relocatable symbol expressions is a
4647 target-specific behavior for this typically target-independent modifier)
4674 It is up to the front-end to make sense of the magic numbers it places
4686 code generator. One example application of metadata is source-level
4689 Metadata does not have a type, and is not a value. If referenced from a
4699 A metadata string is a string surrounded by double quotes. It can
4701 "``\xx``" where "``xx``" is the two digit hex code. For example:
4713 Metadata nodes that aren't uniqued use the ``distinct`` keyword. For example:
4723 A :ref:`named metadata <namedmetadatastructure>` is a collection of
4732 intrinsic is using three metadata arguments:
4738 Metadata can be attached to an instruction. Here metadata ``!21`` is attached
4746 ``!22`` is attached to the ``f1`` and ``f2`` functions, and the globals ``g1``
4759 A transformation is required to drop any metadata attachment that it does not
4760 know or know it can't preserve. Currently there is an exception for metadata
4762 unconditionally dropped unless the global is itself deleted.
4768 optimizers and code generator is found below.
4791 them from instructions). The ``debugInfoForProfiling:`` field is a boolean
4822 Files are sometimes used in ``scope:`` fields, and are the only valid target
4859 refers to a tuple; the first operand is the return type, while the rest are the
4860 types of the formal arguments in order. If the first operand is ``null``, that
4902 ``DW_TAG_member`` is used to define a member of a :ref:`composite type
4903 <DICompositeType>`. The type of the member is the ``baseType:``. The
4904 ``offset:`` is the member's bit offset. If the composite type has an ODR
4905 ``identifier:`` and does not set ``flags: DIFwdDecl``, then the member is
4912 ``DW_TAG_typedef`` is used to provide a name for the ``baseType:``.
4918 Note that the ``void *`` type is expressed as a type derived from NULL.
4961 array type is a native packed vector. The optional ``dataLocation`` is a
4963 raw data, if they aren't equivalent. This is only supported for array types,
4968 and pointee is called association. The optional ``associated`` is a
4969 DIExpression that describes whether the pointer array is currently associated.
4970 The optional ``allocated`` is a DIExpression that describes whether the
4971 allocatable array is currently allocated. The optional ``rank`` is a
4973 rank array (rank is known at runtime).
5113 used for call site debug info. The ``retainedNodes:`` field is a list of
5121 tree as opposed to a definition of a function. If the scope is a composite
5123 then the subprogram declaration is uniqued based only on its ``linkageName:``
5180 ``DILocation`` nodes represent source debug locations. The ``scope:`` field is
5194 the ``arg:`` field is set to non-zero, then this variable is a subprogram
5217 opcodes from the DIExpression until the final variable description is produced.
5219 The current supported opcode vocabulary is limited:
5230 that contrary to DW_OP_bit_piece, the offset is describing the location
5234 expression stack is to be converted. Maps into a ``DW_OP_convert`` operation
5237 optionally applied to the pointer. The memory tag is derived from the
5241 of the stack is treated as an address. The second stack entry is treated as an
5251 the entry value of the debug value instruction's value/address operand is
5252 pushed to the stack, and is added with 123. Due to framework limitations
5255 ``DW_OP_LLVM_entry_value`` is only legal in MIR. The operation is introduced
5257 are unmodified throughout a function. Support is limited to function
5259 indirect locations (e.g. when a struct is passed-by-value to a callee via a
5260 pointer to a temporary copy made in the caller). The entry value op is also
5262 (``DW_AT_call_site_parameter_value``) is represented as entry value of the
5265 signed offset of the specified register. The opcode is only generated by the
5273 rank array which has rank known at run time and current dimension number is
5277 and implicit location descriptions. Note that a location description is
5293 direct value. For example, if the first operand is an indirect value, it may be
5299 A DIExpression is interpreted in the same way regardless of which kind of
5319 union. This flag is used to decide whether the DW_AT_export_symbols can
5347 The ``name:`` field is the macro identifier, followed by macro parameters when
5348 defining a function-like macro, and the ``value`` field is the token-string
5361 The ``nodes:`` field is a list of ``DIMacro`` and ``DIMacroFile`` nodes that
5377 The ``name:`` field is the label identifier. The ``file:`` field is the
5378 :ref:`DIFile` the label is present in. The ``line:`` field is the source line
5379 within the file where the label is declared.
5388 In LLVM IR, memory does not have types, so LLVM's own type system is not
5389 suitable for doing type based alias analysis (TBAA). Instead, metadata is
5394 This description of LLVM's TBAA system is broken into two parts:
5399 It is always possible to trace any TBAA node to a "root" TBAA node (details
5428 type is a scalar type descriptor or a struct type descriptor, the access
5429 type is a scalar type descriptor, and the offset is a constant integer.
5434 * If ``BaseTy`` is a struct type, the tag describes a memory access (load
5438 * If ``BaseTy`` is a scalar type, ``Offset`` must be 0 and ``BaseTy`` and
5445 * If ``BaseTy`` is a scalar type then ``ImmediateParent(BaseTy, 0)`` is
5446 ``(ParentTy, 0)`` where ``ParentTy`` is the parent of the scalar type as
5447 described in the TBAA metadata. ``ImmediateParent(BaseTy, Offset)`` is
5448 undefined if ``Offset`` is non-zero.
5450 * If ``BaseTy`` is a struct type then ``ImmediateParent(BaseTy, Offset)``
5451 is ``(NewTy, NewOffset)`` where ``NewTy`` is the type contained in
5452 ``BaseTy`` at offset ``Offset`` and ``NewOffset`` is ``Offset`` adjusted
5457 Offset2)`` if either ``(BaseTy1, Offset1)`` is reachable from ``(Base2,
5482 is (note that in C and C++, ``char`` can be used to access any arbitrary
5506 The root node of a TBAA type hierarchy is an ``MDNode`` with 0 operands or
5510 operands. The first operand is an ``MDString`` denoting the name of the
5512 only cares about it being an ``MDString``. The second operand is an
5514 which is either another scalar type descriptor or the TBAA root. Scalar
5519 of operands greater than 1. The first operand is an ``MDString`` denoting
5521 value of this name operand is irrelevant to LLVM. After the name operand,
5525 ``ConstantInt``, is the offset of the said contained field. The offsets
5529 The first operand is an ``MDNode`` pointing to the node representing the
5530 base type. The second operand is an ``MDNode`` pointing to the node
5531 representing the access type. The third operand is a ``ConstantInt`` that
5532 states the offset of the access. If a fourth field is present, it must be
5533 a ``ConstantInt`` valued at 0 or 1. If it is 1 then the access tag states
5534 that the location being accessed is "constant" (meaning
5538 that is the TBAA root of the access tag.
5543 The :ref:`llvm.memcpy <int_memcpy>` is often used to implement
5545 is defined to copy a contiguous region of memory, which is more than
5553 The current metadata format is very simple. ``!tbaa.struct`` metadata
5563 This describes a struct with two fields. The first is at offset 0 bytes
5564 with size 4 bytes, and has tbaa tag !1. The second is at offset 8 bytes
5567 Note that the fields need not be contiguous. In this example, there is a
5583 of scopes with that domain in one instruction's ``alias.scope`` list is a
5589 domains can be used to compose multiple independent noalias sets. This is
5591 turned into noalias scope metadata, a new domain is used every time the
5592 function is inlined.
5594 The metadata identifying each domain is itself a list containing one or two
5595 entries. The first entry is the name of the domain. Note that if the name is a
5600 The metadata identifying each scope is also itself a list containing two or
5601 three entries. The first entry is the name of the scope. Note that if the name
5602 is a string then it can be combined across functions and translation units. A
5604 reference to the scope's domain is the second entry. A descriptive string may
5635 ; the !noalias list is not a superset of, or equal to, the scopes in the
5647 it. ULP is defined as follows:
5649 If ``x`` is a real number that lies between two finite consecutive
5651 of them, then ``ulp(x) = |b - a|``, otherwise ``ulp(x)`` is the
5653 nearest ``x``. Moreover, ``ulp(NaN)`` is ``NaN``.
5660 !0 = !{ float 2.5 } ; maximum acceptable inaccuracy is 2.5 ULPs
5669 returned by the called function at this call site is in. If the loaded or
5670 returned value is not in the specified range, the behavior is undefined. The
5672 the value returned is known to be in the union of the ranges defined by each
5678 - The range is allowed to wrap.
5679 - The range should not represent the full or empty set. That is,
5707 global variable's *address* (not its value) is in, in the same format as
5726 metadata is attached to a call site, and any callee is not among the set of
5727 functions provided by the metadata, the behavior is undefined. The intent of
5728 this metadata is to facilitate optimizations such as indirect-call promotion.
5729 For example, in the code below, the call instruction may only target the
5749 semantic restriction on the broker function itself is that it is not allowed to
5753 The broker is not required to actually invoke the callback function at runtime.
5756 function is not dynamically invoked. The broker is allowed to invoke the
5757 callback function more than once per invocation of the broker. The broker is
5759 callback through another use. Finally, the broker is also allowed to relay the
5762 The metadata is structured as follows: At the outer level, ``callback``
5763 metadata is a list of ``callback`` encodings. Each encoding starts with a
5766 what arguments are passed to the callback function. Each element is again an
5767 ``i64`` constant identifying the argument of the broker that is passed through,
5770 callee. The last element of the encoding is a boolean which specifies how
5771 variadic arguments of the broker are handled. If it is true, all variadic
5775 In the code below, the ``pthread_create`` function is marked as a broker
5776 through the ``!callback !1`` metadata. In the example, there is only one
5783 error if the below is set to highlight as 'llvm', despite that we
5794 Another example is shown below. The callback callee is the second argument of
5795 the ``__kmpc_fork_call`` function (``i64 2``). The callee is given two unknown
5801 error if the below is set to highlight as 'llvm', despite that we
5820 is treated as a boolean value; if it exists, it signals that the branch
5821 or switch that it is attached to is completely unpredictable.
5829 tells the optimizer that the value loaded is known to be dereferenceable.
5830 The number of bytes known to be dereferenceable is specified by the integer
5831 value in the metadata node. This is analogous to the ''dereferenceable''
5840 instruction tells the optimizer that the value loaded is known to be either
5842 The number of bytes known to be dereferenceable is specified by the integer
5843 value in the metadata node. This is analogous to the ''dereferenceable_or_null''
5851 It is sometimes useful to attach information to loop constructs. Currently,
5852 loop metadata is implemented as metadata attached to the branch instruction
5853 in the loop latch block. The loop metadata node is a list of
5855 the first item of the property node is a string. For example, the
5868 reference to itself. Before the advent of the 'distinct' keyword, this
5871 keyword has become unnecessary.
5887 ``llvm.loop.unroll.enable``. That is, no heuristic will try to determine
5888 whether a transformation is profitable. The purpose is to avoid that the
5889 loop is transformed to a different loop before an explicitly requested
5890 (forced) transformation is applied. For instance, loop fusion can make
5894 It is recommended to use this metadata in addition to any llvm.loop.*
5911 it believes it is safe to do so. The ``llvm.loop.parallel_accesses`` metadata
5919 The first operand is the string ``llvm.loop.interleave.count`` and the
5920 second operand is an integer specifying the interleave count. For
5928 multiple iterations of the loop. If ``llvm.loop.interleave.count`` is set to 0
5935 first operand is the string ``llvm.loop.vectorize.enable`` and the second operand
5936 is a bit. If the bit operand value is 1 vectorization is enabled. A value of
5949 main loop. The first operand is the string
5950 ``llvm.loop.vectorize.predicate.enable`` and the second operand is a bit. If
5951 the bit operand value is 1 vectorization is enabled. A value of 0 disables
5963 loop, and only has any effect if vectorization for the loop is already enabled.
5964 The first operand is the string ``llvm.loop.vectorize.scalable.enable``
5965 and the second operand is a bit. If the bit operand value is 1 scalable
5966 vectorization is enabled, whereas a value of 0 reverts to the default fixed
5977 This metadata sets the target width of the vectorizer. The first
5978 operand is the string ``llvm.loop.vectorize.width`` and the second
5979 operand is an integer specifying the width. For example:
5986 vectorization of the loop. If ``llvm.loop.vectorize.width`` is set to
6000 epilogue is not vectorized and is executed when either the vectorized
6001 loop is not known to preserve semantics (because e.g., it processes two
6021 optimizer believes it is safe to do so.
6027 first operand is the string ``llvm.loop.unroll.count`` and the second
6028 operand is a positive integer specifying the unroll factor. For
6035 If the trip count of the loop is less than the unroll count the loop
6042 which is the string ``llvm.loop.unroll.disable``. For example:
6052 operand which is the string ``llvm.loop.unroll.runtime.disable``. For example:
6062 is known at compile time and partially unrolled if the trip count is not known
6063 at compile time. The metadata has a single operand which is the string
6074 metadata has a single operand which is the string ``llvm.loop.unroll.full``.
6097 This metadata is treated very similarly to the ``llvm.loop.unroll`` metadata
6104 The metadata for unroll and jam otherwise is the same as for ``unroll``.
6107 ``llvm.loop.unroll_and_jam.full`` is not supported. Again these are only hints
6114 ``llvm.loop.unroll.count``. The first operand is the string
6115 ``llvm.loop.unroll_and_jam.count`` and the second operand is a positive integer
6122 If the trip count of the loop is less than the unroll count the loop
6129 operand which is the string ``llvm.loop.unroll_and_jam.disable``. For example:
6139 trip count is known at compile time and partially unrolled if the trip count is
6140 not known at compile time. The metadata has a single operand which is the
6165 will have. This loop is usually unrolled, meaning there is no such
6180 Attributes specified in the metadata is added to all
6189 which is the string ``llvm.loop.licm_versioning.disable``. For example:
6199 this is only performed if the entire loop cannot be vectorized due to unsafe
6204 loop. The first operand is the string ``llvm.loop.distribute.enable`` and the
6205 second operand is a bit. If the bit operand value is 1 distribution is
6233 If loop versioning is necessary, this metadata defined the attributes
6240 The attributes in this metadata is added to all followup loops of the
6248 performed on this loop. The metadata has a single operand which is the string
6256 as it is not affected by the ``llvm.loop.disable_nonforced`` metadata.
6276 It is illegal for the list node to be empty since it might be confused
6283 situation that the content must be updated which, because metadata is
6288 without pointing to it directly (which is not possible in global
6289 metadata). Currently, the only metadata making use of it is
6304 assume that there is no dependency between ``m1`` and ``m2`` carried by
6312 loop has no loop carried memory dependences and is considered to be a
6318 memory dependence analysis is required to make that determination. As a fail
6323 Example of a loop that is considered parallel due to its correct use of
6342 It is also possible to have nested parallel loops:
6376 The ``llvm.loop.mustprogress`` metadata indicates that this loop is required to
6378 via a volatile memory access, I/O, or other synchronization. If such a loop is
6387 than once header basic blocks.) If ``irr_loop`` metadata is attached to the
6388 terminator instruction of a basic block that is not really an irreducible loop
6389 header, the behavior is undefined. The intent of this metadata is to improve the
6450 another based on aliasing information. This is because invariant.group is tied
6459 Note that this is an experimental feature, which means that its semantics might
6474 unless the referenced object is also discarded. The linker support for
6475 this feature is spotty. For best compatibility, globals carrying this
6480 - Have an explicit section with a name which is a valid C identifier.
6497 The ``prof`` metadata is used to record profile data in the IR.
6519 to record the number of times the function is called. Used with BFI
6520 information, it is also used to derive the basic block profile count.
6529 value profile information. Currently this is indirect calls (where it
6535 is executed, followed by uint64_t value and execution count pairs.
6536 The value profiling kind is 0 for indirect call targets and 1 for memory
6537 operations. For indirect call targets, each profile value is a hash
6538 of the callee function name, and for memory operations each value is the
6552 Note that the VP type is 0 (the second operand), which indicates this is
6555 hashes of the 2 hottest target functions' names (this is the same hash used
6557 operands give the execution count that each of the respective prior target
6580 Information about the module as a whole is difficult to convey to LLVM's
6590 - The first element is a *behavior* flag, which specifies the behavior
6594 - The second element is a metadata string that is a unique ID for the
6597 - The third element is the value of the flag.
6600 ``llvm.module.flags`` metadata is the union of the modules' flags. That is, for
6604 is that entries with the *Require* behavior are always preserved.
6618 is that of the operands.
6630 specified value after linking is performed. The value must be a
6631 metadata pair, where the first element of the pair is the ID of the
6632 module flag to be restricted, and the second element of the pair is
6657 It is an error for a particular unique flag ID to have multiple behaviors,
6676 if two or more ``!"foo"`` flags are seen is to emit an error if their
6680 behavior if two or more ``!"bar"`` flags are seen is to use the value
6684 behavior if two or more ``!"qux"`` flags are seen is to emit a
6693 The behavior is to emit an error if the ``llvm.module.flags`` does not
6694 contain a flag with the ID ``!"foo"`` that has the value '1' after linking is
6731 - **[Required]** --- Specifies whether garbage collection is supported or
6736 - **[Optional]** --- Specifies that only garbage collection is supported.
6742 - If a module with ``Objective-C Garbage Collection`` set to 0 is
6779 enum is the smallest type which can represent all of its values::
6788 Some optimisations are only when the entire LTO unit is present in the current
6789 module. This is represented by the ``LTOPostLink`` module flags metadata, which
6796 files. Typically this is used in conjunction with language extensions which
6801 ``!llvm.linker.options``. Each operand is expected to be a metadata node
6814 list of options, is chosen so that the IR encoding can use multiple option
6816 preserved as an atomic element that can be recognized by a target specific
6819 Each individual option is required to be either a valid option for the target's
6820 linker, or an option that is reserved by the target specific assembly writer or
6821 object file emitter. No other aspect of these options is defined by the IR.
6827 a set of libraries to add to the link. Typically this is used in conjunction
6832 The list is encoded in the IR using named metadata with the name
6833 ``!llvm.dependent-libraries``. Each operand is expected to be a metadata node
6851 causes the building of a compact summary of the module that is emitted into
6852 the bitcode. The summary is emitted into the LLVM assembly and identified
6855 The summary is parsed into a bitcode output, along with the Module
6862 the same conditions where summary index is currently built from bitcode.
6866 (this part is not yet implemented, use llvm-as to create a bitcode object
6890 The ``path`` field is a string path to the bitcode file, and the ``hash``
6891 field is the 160-bit SHA-1 hash of the IR bitcode contents, used for
6913 Each ``Summary`` format will depend on whether the global value is a
6922 If the global value is a function, the ``Summary`` entry will look like:
6930 the linkage type, a flag indicating whether it is legal to import the
6931 definition, whether it is globally live and whether the linker resolved it
6943 If the global value is a variable, the ``Summary`` entry will look like:
6957 If the global value is an alias, the ``Summary`` entry will look like:
7009 The optional ``Params`` is used by ``StackSafety`` and looks like:
7022 where the first ``param`` is the number of the parameter it describes,
7023 ``offset`` is the inclusive range of offsets from the pointer parameter to bytes
7027 where each ``Callee`` describes how parameter is forwarded into other
7034 The ``callee`` refers to the summary entry id of the callee, ``param`` is
7040 Pointer parameter without corresponding ``Param`` is considered unsafe and we
7041 assume that access with any offset is possible.
7065 The function may access just 8 bytes of the parameter %0 . ``calls`` is empty,
7066 so the parameter is either not used for function calls or ``offset`` already
7068 Parameter %1 escapes, so access is unknown.
7070 access is possible inside of the ``@bar`` or ``^3``. The function adds signed
7073 Parameter %3 is not a pointer.
7153 and each Arg is an integer argument number.
7171 which is generated during the LTO link portion of the compile when building
7183 the ``size-1`` bit width. It is followed by optional flags, which default to 0,
7191 where each entry is a mapping from the given byte offset to the whole-program
7207 where ResByArg is:
7214 or ``VirtualConstProp``. The ``info`` field is only used if the kind
7215 is ``UniformRetVal`` (indicates the uniform return value), or
7217 (0 or 1)). The ``byte`` and ``bit`` fields are only used if the target does
7236 The ``@llvm.used`` global is an array which has
7240 use of it is:
7253 and linker are required to treat the symbol as if there is a reference to the
7254 symbol that it cannot see (which is why they have to be named). For example, if
7256 ``@llvm.used`` list, it cannot be deleted. This is commonly used to represent
7269 The ``@llvm.compiler.used`` directive is the same as the ``@llvm.used``
7275 This is a rare construct that should only be used in rare circumstances,
7291 of priority (i.e. lowest first) when the module is loaded. The order of
7292 functions with the same priority is not defined.
7294 If the third field is non-null, and points to a global variable
7296 data from the current module is not discarded.
7311 order of priority (i.e. highest first) when the module is unloaded. The
7312 order of functions with the same priority is not defined.
7314 If the third field is non-null, and points to a global variable
7316 data from the current module is not discarded.
7334 block should be executed after the current block is finished. These
7364 The '``ret``' instruction is used to return control flow (and optionally
7378 A function is not :ref:`well formed <wellformed>` if it has a non-void
7387 When the '``ret``' instruction is executed, control flow returns back to
7388 the calling function's context. If the caller is a
7421 The '``br``' instruction is used to cause control flow to transfer to a
7431 '``br``' instruction takes a single '``label``' value as a target.
7437 argument is evaluated. If the value is ``true``, control flows to the
7438 '``iftrue``' ``label`` argument. If "cond" is ``false``, control flows
7440 If '``cond``' is ``poison`` or ``undef``, this instruction has undefined
7471 The '``switch``' instruction is used to transfer control flow to one of
7472 several different places. It is a generalization of the '``br``'
7482 is not allowed to contain duplicate constant entries.
7488 When the '``switch``' instruction is executed, this table is searched
7489 for the given value. If the value is found, control flow is transferred
7490 to the corresponding destination; otherwise, control flow is transferred
7492 If '``value``' is ``poison`` or ``undef``, this instruction has undefined
7498 Depending on properties of the target machine and the particular
7536 label within the current function, whose address is specified by
7543 The '``address``' argument is the address of the label to jump to. The
7548 This destination list is required so that dataflow analysis has an
7558 If '``address``' is ``poison`` or ``undef``, this instruction has undefined
7564 This is typically implemented with a jump through a register.
7595 mechanism, control is interrupted and continued at the dynamically
7598 The '``exception``' label is a `landing
7600 '``exception``' label is required to have the
7614 convention <callingconv>` the call should use. If none is
7620 of the called function. If it is not specified, the program address space
7622 #. '``ty``': the type of the call instruction itself which is also the
7627 type can be omitted if the function is not varargs.
7629 be invoked. In most cases, this is a direct function invocation, but
7648 This instruction is designed to operate as a standard '``call``'
7649 instruction in most regards. The primary difference is that it
7650 establishes an association with a label, which is used by the runtime
7653 This instruction is used in languages with destructors to ensure that
7654 proper cleanup is performed in the case of either a ``longjmp`` or a
7655 thrown exception. Additionally, this is important for implementation of
7659 by the '``invoke``' instruction is deemed to occur on the edge from the
7661 return value is available.
7694 style inline assembly. Any other usage is an error in the IR verifier.
7702 convention <callingconv>` the call should use. If none is
7708 of the called function. If it is not specified, the program address space
7710 #. '``ty``': the type of the call instruction itself which is also the
7715 type can be omitted if the function is not varargs.
7717 be called. In most cases, this is a direct function call, but
7736 This instruction is designed to operate as a standard '``call``'
7737 instruction in most regards. The primary difference is that it
7744 The only use of this today is to implement the "goto" feature of gcc inline
7776 The '``resume``' instruction is a terminator instruction that has no
7816 The '``catchswitch``' instruction is used by `LLVM's exception handling system
7823 The ``parent`` argument is the token of the funclet that contains the
7824 ``catchswitch`` instruction. If the ``catchswitch`` is not inside a funclet,
7827 The ``default`` argument is the label of another basic block beginning with
7829 must be a legal target with respect to the ``parent`` links, as described in
7842 The ``catchswitch`` is both a terminator and a "pad" instruction, meaning that
7871 The '``catchret``' instruction is a terminator instruction that has a
7893 If the specified ``catchpad`` is not the most-recently-entered not-yet-exited
7895 the ``catchret``'s behavior is undefined.
7920 The '``cleanupret``' instruction is a terminator instruction that has
7929 If the specified ``cleanuppad`` is not the most-recently-entered not-yet-exited
7931 the ``cleanupret``'s behavior is undefined.
7936 be a legal target with respect to the ``parent`` links, as described in the
7971 instruction is used to inform the optimizer that a particular portion of
7972 the code is not reachable. This can be used to indicate that the code
7987 data, as is the case with the :ref:`vector <t_vector>` data type. The
8017 The value produced is a copy of the operand with its sign bit flipped.
8037 data, as is the case with the :ref:`vector <t_vector>` data type. The
8072 The value produced is the integer sum of the two operands.
8074 If the sum has unsigned overflow, the result returned is the
8075 mathematical result modulo 2\ :sup:`n`\ , where n is the bit width of
8079 instruction is appropriate for both signed and unsigned integers.
8083 result value of the ``add`` is a :ref:`poison value <poisonvalues>` if
8120 The value produced is the floating-point sum of the two operands.
8121 This instruction is assumed to execute in the default :ref:`floating-point
8154 Note that the '``sub``' instruction is used to represent the '``neg``'
8167 The value produced is the integer difference of the two operands.
8169 If the difference has unsigned overflow, the result returned is the
8170 mathematical result modulo 2\ :sup:`n`\ , where n is the bit width of
8174 instruction is appropriate for both signed and unsigned integers.
8178 result value of the ``sub`` is a :ref:`poison value <poisonvalues>` if
8216 The value produced is the floating-point difference of the two operands.
8217 This instruction is assumed to execute in the default :ref:`floating-point
8261 The value produced is the integer product of the two operands.
8264 returned is the mathematical result modulo 2\ :sup:`n`\ , where n is the
8268 result is the same width as the operands, this instruction returns the
8270 (e.g. ``i32`` * ``i32`` -> ``i64``) is needed, the operands should be
8276 result value of the ``mul`` is a :ref:`poison value <poisonvalues>` if
8313 The value produced is the floating-point product of the two operands.
8314 This instruction is assumed to execute in the default :ref:`floating-point
8355 The value produced is the unsigned integer quotient of the two operands.
8360 Division by zero is undefined behavior. For vectors, if any element
8361 of the divisor is zero, the operation has undefined behavior.
8364 If the ``exact`` keyword is present, the result value of the ``udiv`` is
8365 a :ref:`poison value <poisonvalues>` if %op1 is not a multiple of %op2 (as
8403 The value produced is the signed integer quotient of the two operands
8409 Division by zero is undefined behavior. For vectors, if any element
8410 of the divisor is zero, the operation has undefined behavior.
8411 Overflow also leads to undefined behavior; this is a rare case, but can
8414 If the ``exact`` keyword is present, the result value of the ``sdiv`` is
8451 The value produced is the floating-point quotient of the two operands.
8452 This instruction is assumed to execute in the default :ref:`floating-point
8500 Taking the remainder of a division by zero is undefined behavior.
8501 For vectors, if any element of the divisor is zero, the operation has
8542 is either zero or has the same sign as the dividend, ``op1``), not the
8543 *modulo* operator (where the result is either zero or has the same sign
8547 table of how this is implemented in various languages, please see
8554 Taking the remainder of a division by zero is undefined behavior.
8555 For vectors, if any element of the divisor is zero, the operation has
8557 Overflow also leads to undefined behavior; this is a rare case, but can
8598 The value produced is the floating-point remainder of the two operands.
8599 This is the same output as a libm '``fmod``' function, but without any
8602 This instruction is assumed to execute in the default :ref:`floating-point
8624 single value. The resulting value is the same type as its operands.
8652 '``op2``' is treated as an unsigned value.
8657 The value produced is ``op1`` \* 2\ :sup:`op2` mod 2\ :sup:`n`,
8658 where ``n`` is the width of the result. If ``op2`` is (statically or
8661 If the arguments are vectors, each vector element of ``op1`` is shifted
8664 If the ``nuw`` keyword is present, then the shift produces a poison
8666 If the ``nsw`` keyword is present, then the shift produces a poison
8705 '``op2``' is treated as an unsigned value.
8712 the shift. If ``op2`` is (statically or dynamically) equal to or larger
8715 of ``op1`` is shifted by the corresponding shift amount in ``op2``.
8717 If the ``exact`` keyword is present, the result value of the ``lshr`` is
8757 '``op2``' is treated as an unsigned value.
8764 of ``op1``. If ``op2`` is (statically or dynamically) equal to or larger
8767 of ``op1`` is shifted by the corresponding shift amount in ``op2``.
8769 If the ``exact`` keyword is present, the result value of the ``ashr`` is
8812 The truth table used for the '``and``' instruction is:
8863 The truth table used for the '``or``' instruction is:
8902 its two operands. The ``xor`` is used to implement the "one's
8903 complement" operation, which is the "~" operator in C.
8915 The truth table used for the '``xor``' instruction is:
8943 target-independent manner. These instructions cover the element-access
8946 sophisticated algorithms will want to use target-specific intrinsics to
8947 take full advantage of a specific target.
8971 The first operand of an '``extractelement``' instruction is a value of
8972 :ref:`vector <t_vector>` type. The second operand is an index indicating
8979 The result is a scalar of the same type as the element type of ``val``.
8980 Its value is the value at position ``idx`` of ``val``. If ``idx``
8981 exceeds the length of ``val`` for a fixed-length vector, the result is a
8983 of ``idx`` exceeds the runtime length of the vector, the result is a
9015 The first operand of an '``insertelement``' instruction is a value of
9016 :ref:`vector <t_vector>` type. The second operand is a scalar value whose
9018 is an index indicating the position at which to insert the value. The
9024 The result is a vector of the same type as ``val``. Its element values
9027 the result is a :ref:`poison value <poisonvalues>`. For a scalable vector,
9029 is a :ref:`poison value <poisonvalues>`.
9056 the input and length that is the same as the shuffle mask.
9062 with the same type. The third argument is a shuffle mask vector constant
9063 whose element type is ``i32``. The mask vector elements must be constant
9064 integers or ``undef`` values. The result of the instruction is a vector
9065 whose length is the same as the shuffle mask and whose element type is the
9077 If the shuffle mask is undefined, the result vector is undefined. If
9079 vectors, the resulting element is undefined. An undefined element
9080 in the mask vector specifies that the resulting element is undefined.
9129 The first operand of an '``extractvalue``' instruction is a value of
9136 - Since the value being indexed is not a pointer, the first index is
9144 The result is the value at the position in the aggregate specified by
9175 The first operand of an '``insertvalue``' instruction is a value of
9176 :ref:`struct <t_struct>` or :ref:`array <t_array>` type. The second operand is
9186 The result is an aggregate of the same type as ``val``. Its value is
9188 indices is that of ``elt``.
9204 A key design point of an SSA-based representation is how it represents
9226 function returns to its caller. The object is always allocated in the
9234 appropriate type to the program. If "NumElements" is specified, it is
9235 the number of elements allocated, otherwise "NumElements" is defaulted
9236 to be one. If a constant alignment is specified, the value result of the
9237 allocation is guaranteed to be aligned to at least that boundary. The
9239 zero, the target can choose to align the allocation on any convenient
9247 Memory is allocated; a pointer is returned. The allocated memory is
9249 value. The operation itself is undefined if there is insufficient stack
9250 space for the allocation.'``alloca``'d memory is automatically released
9251 when the function returns. The '``alloca``' instruction is commonly used
9254 the memory is reclaimed. Allocating zero bytes is legal, but the returned
9255 pointer may not be unique. The order in which memory is allocated (ie.,
9256 which way the stack grows) is not specified.
9279 …<result> = load atomic [volatile] <ty>, <ty>* <pointer> [syncscope("<target-scope>")] <ordering>, …
9288 The '``load``' instruction is used to read from memory.
9296 the ``load`` is marked as ``volatile``, then the optimizer is not allowed to
9300 If the ``load`` is marked as ``atomic``, it takes an extra :ref:`ordering
9301 <ordering>` and optional ``syncscope("<target-scope>")`` argument. The
9305 floating-point type whose bit width is a power of two greater than or equal to
9306 eight and less than or equal to a target-specific size limit. ``align`` must be
9308 alignment is not set to a value which is at least the size in bytes of the
9312 operation (that is, the alignment of the memory address). A value of 0
9314 alignment for the target. It is the responsibility of the code emitter
9315 to ensure that the alignment information is correct. Overestimating the
9317 may produce less efficient code. An alignment of 1 is always safe. The
9318 maximum possible alignment is ``1 << 29``. An alignment value higher
9329 that this load is not expected to be reused in the cache. The code
9336 metadata is executed, the optimizer may assume the memory location
9338 program where the memory location is known to be dereferenceable;
9339 otherwise, the behavior is undefined.
9348 instruction tells the optimizer that the value loaded is known to
9349 never be null. If the value is null at runtime, the behavior is undefined.
9350 This is analogous to the ``nonnull`` attribute on parameters and return
9367 optimizer that the value loaded is known to be aligned to a boundary specified
9369 This is analogous to the ''align'' attribute on parameters and return values.
9371 value is not appropriately aligned at runtime, the behavior is undefined.
9376 loaded is known to be :ref:`well defined <welldefinedvalues>`.
9377 If the value isn't well defined, the behavior is undefined.
9382 The location of memory pointed to is loaded. If the value being loaded
9383 is of scalar type then the number of bytes read does not exceed the
9386 value of a type like ``i20`` with a size that is not an integral number
9387 of bytes, the result is undefined if the value was not originally
9389 If the value being loaded is of aggregate type, the bytes that correspond to
9390 padding may be accessed but are ignored, because it is impossible to observe
9393 If the pointer is not a well-defined value, all of its possible representations
9395 array of type ``[16 x i8]`` with offset ``undef & 31`` is undefined behavior.
9419 …store atomic [volatile] <ty> <value>, <ty>* <pointer> [syncscope("<target-scope>")] <ordering>, al…
9426 The '``store``' instruction is used to write to memory.
9434 operand. If the ``store`` is marked as ``volatile``, then the optimizer is not
9440 If the ``store`` is marked as ``atomic``, it takes an extra :ref:`ordering
9441 <ordering>` and optional ``syncscope("<target-scope>")`` argument. The
9445 floating-point type whose bit width is a power of two greater than or equal to
9446 eight and less than or equal to a target-specific size limit. ``align`` must be
9448 the alignment is not set to a value which is at least the size in bytes of the
9452 operation (that is, the alignment of the memory address). A value of 0
9454 alignment for the target. It is the responsibility of the code emitter
9455 to ensure that the alignment information is correct. Overestimating the
9457 alignment may produce less efficient code. An alignment of 1 is always
9458 safe. The maximum possible alignment is ``1 << 29``. An alignment
9463 data race is not allowed. Storing to the extra bytes is not allowed
9464 even in situations where a data race is known to not exist if the
9470 tells the optimizer and code generator that this load is not expected to
9482 location specified by the ``<pointer>`` operand. If ``<value>`` is
9486 value of a type like ``i20`` with a size that is not an integral number
9487 of bytes, it is unspecified what happens to the extra bits that do not
9489 If ``<value>`` is of aggregate type, padding is filled with
9492 If ``<pointer>`` is not a well-defined value, all of its possible
9494 pointer to an array of type ``[16 x i8]`` with offset ``undef & 31`` is
9517 fence [syncscope("<target-scope>")] <ordering> ; yields void
9522 The '``fence``' instruction is used to introduce happens-before edges
9538 operating on some atomic object M, such that A is sequenced before X, X
9540 headed by X), Y is sequenced before B, and Y observes M. This provides a
9573 …cmpxchg [weak] [volatile] <ty>* <pointer>, <ty> <cmp>, <ty> <new> [syncscope("<target-scope>")] <s…
9578 The '``cmpxchg``' instruction is used to atomically modify memory. It
9589 bit width is a power of two greater than or equal to eight and less
9590 than or equal to a target-specific size limit. '<cmp>' and '<new>' must
9592 that type. If the ``cmpxchg`` is marked as ``volatile``, then the
9593 optimizer is not allowed to modify the number or order of execution of
9612 is read and compared to '``<cmp>``'; if the values are equal, '``<new>``' is
9613 written to the location. The original value at the location is returned,
9616 If the cmpxchg operation is marked as ``weak`` then a spurious failure is
9620 If the cmpxchg operation is strong (the default), the i1 value is 1 if and only
9623 A successful ``cmpxchg`` is a read-modify-write instruction for the purpose of
9624 identifying release sequences. A failed ``cmpxchg`` is equivalent to an atomic
9657 …atomicrmw [volatile] <operation> <ty>* <pointer>, <ty> <value> [syncscope("<target-scope>")] <orde…
9662 The '``atomicrmw``' instruction is used to atomically modify memory.
9686 type whose bit width is a power of two greater than or equal to eight
9687 and less than or equal to a target-specific size limit. For xchg, this
9691 the ``atomicrmw`` is marked as ``volatile``, then the optimizer is not
9703 value at the location is returned. The modification is specified by the
9746 The '``getelementptr``' instruction is used to get the address of a
9754 The first argument is always a type used as the basis for the calculations.
9755 The second argument is always a pointer or a vector of pointers, and is the
9758 The interpretation of each index is dependent on the type being indexed
9767 The type of each index argument depends on the type it is indexing into.
9795 The LLVM code generated by Clang is:
9811 In the example above, the first index is indexing into the
9812 '``%struct.ST*``' type, which is a pointer, yielding a '``%struct.ST``'
9822 Note that it is perfectly legal to index partially through a structure,
9824 for the given testcase is equivalent to:
9837 If the ``inbounds`` keyword is present, the result value of the
9838 ``getelementptr`` is a :ref:`poison value <poisonvalues>` if one of the
9839 following rules is violated:
9843 *in bounds* address for a null pointer in the default address-space is the
9845 * If the type of an index is larger than the pointer index type, the
9854 As a corollary, if the added offset is non-negative, the addition does not
9856 * In cases where the base is a vector of pointers, the ``inbounds`` keyword
9863 If the ``inbounds`` keyword is not present, the offsets are added to the
9873 If the ``inrange`` keyword is present before any index, loading from or
9879 the ``inrange`` keyword is undefined, with the exception of comparisons
9881 by the ``inrange`` keyword, inclusive of the address one past the end of
9882 that element. Note that the ``inrange`` keyword is currently only allowed
9885 The getelementptr instruction is often confusing. For some more insight
9906 when one or more of its arguments is a vector. In such cases, all vector
9924 ; In all cases described above the type of the result is <4 x i8*>
10123 This instruction is assumed to execute in the default :ref:`floating-point
10196 ``ty`` is a vector floating-point type, ``ty2`` must be a vector integer
10205 is a :ref:`poison value <poisonvalues>`.
10238 ``ty`` is a vector floating-point type, ``ty2`` must be a vector integer
10247 is a :ref:`poison value <poisonvalues>`.
10280 ``ty`` is a vector integer type, ``ty2`` must be a vector floating-point
10288 value. If the value cannot be exactly represented, it is rounded using
10322 ``ty`` is a vector integer type, ``ty2`` must be a vector floating-point
10330 value cannot be exactly represented, it is rounded using the default rounding
10373 If ``value`` is smaller than ``ty2`` then a zero extension is done. If
10374 ``value`` is larger than ``ty2`` then a truncation is done. If they are
10375 the same size, then nothing is done (*no-op cast*) other than a type
10427 of the integer ``value``. If ``value`` is larger than the size of a
10428 pointer then a truncation is done. If ``value`` is smaller than the size
10429 of a pointer then a zero extension is done. If they are the same size,
10430 nothing is done (*no-op cast*).
10467 identical. If the source type is a pointer, the destination type must
10476 is always a *no-op cast* because no bits change with this
10477 conversion. The conversion is done as if the ``value`` had been stored
10524 value modification, depending on the target and the address space
10527 conversion is legal then both result and operand refer to the same memory
10569 The '``icmp``' instruction takes three operands. The first operand is
10570 the condition code indicating the kind of comparison to perform. It is
10571 not a value, just a keyword. The possible condition codes are:
10596 otherwise. No sign interpretation is necessary or performed.
10598 otherwise. No sign interpretation is necessary or performed.
10600 ``true`` if ``op1`` is greater than ``op2``.
10602 ``true`` if ``op1`` is greater than or equal to ``op2``.
10604 ``true`` if ``op1`` is less than ``op2``.
10606 ``true`` if ``op1`` is less than or equal to ``op2``.
10608 if ``op1`` is greater than ``op2``.
10610 if ``op1`` is greater than or equal to ``op2``.
10612 if ``op1`` is less than ``op2``.
10614 if ``op1`` is less than or equal to ``op2``.
10620 element. The result is an ``i1`` vector with the same number of elements
10621 as the values being compared. Otherwise, the result is an ``i1``.
10653 If the operands are floating-point scalars, then the result type is a
10656 If the operands are floating-point vectors, then the result type is a
10663 The '``fcmp``' instruction takes three operands. The first operand is
10664 the condition code indicating the kind of comparison to perform. It is
10665 not a value, just a keyword. The possible condition codes are:
10684 *Ordered* means that neither operand is a QNAN while *unordered* means
10701 is equal to ``op2``.
10703 is greater than ``op2``.
10705 is greater than or equal to ``op2``.
10707 is less than ``op2``.
10709 is less than or equal to ``op2``.
10711 is not equal to ``op2``.
10713 #. ``ueq``: yields ``true`` if either operand is a QNAN or ``op1`` is
10715 #. ``ugt``: yields ``true`` if either operand is a QNAN or ``op1`` is
10717 #. ``uge``: yields ``true`` if either operand is a QNAN or ``op1`` is
10719 #. ``ult``: yields ``true`` if either operand is a QNAN or ``op1`` is
10721 #. ``ule``: yields ``true`` if either operand is a QNAN or ``op1`` is
10723 #. ``une``: yields ``true`` if either operand is a QNAN or ``op1`` is
10725 #. ``uno``: yields ``true`` if either operand is a QNAN.
10762 The '``phi``' instruction is used to implement the φ node in the SSA
10768 The type of the incoming values is specified with the first type field.
10779 For the purposes of the SSA form, the use of each incoming value is
10820 selty is either i1 or {<N x i1>}
10825 The '``select``' instruction is used to choose one value based on a
10844 If the condition is an i1 and it evaluates to 1, the instruction returns
10848 If the condition is a vector of i1, then the value arguments must be
10849 vectors of the same size, and the selection is done element by element.
10851 If the condition is an i1 and the value arguments are vectors of the
10852 same size, then an entire vector is selected.
10877 The '``freeze``' instruction is used to stop propagation of
10888 If the argument is ``undef`` or ``poison``, '``freeze``' returns an
10890 Otherwise, this instruction is a no-op and returns the input argument.
10895 While ``undef`` and ``poison`` pointers can be frozen, the result is a
10898 If an aggregate value or vector is frozen, the operand is frozen element-wise.
10956 should perform tail call optimization. The ``tail`` marker is a hint that
10961 #. The call will not cause unbounded stack growth if it is part of a
10968 the return value of the callee is returned to the caller's caller, even
10969 if a void return type is in use.
10986 - The callee must be varargs iff the caller is varargs. Bitcasting a
10987 non-varargs function to the appropriate varargs type is legal so
10990 Tail call optimization for calls marked ``tail`` is guaranteed to occur if
10994 - The call is in tail position (ret immediately follows call and ret
10995 uses value of call or is void).
10996 - Option ``-tailcallopt`` is enabled,
10997 ``llvm::GuaranteedTailCallOpt`` is ``true``, or the calling convention
10998 is ``tailcc``
11003 ``tail`` or ``musttail`` markers to the call. It is used to prevent tail
11013 convention <callingconv>` the call should use. If none is
11016 the target function, or else the behavior is undefined.
11021 of the called function. If it is not specified, the program address space
11023 #. '``ty``': the type of the call instruction itself which is also the
11028 type can be omitted if the function is not varargs.
11030 be called. In most cases, this is a direct function call, but
11044 The '``call``' instruction is used to cause control flow to transfer to
11048 return value of the function is bound to the result argument.
11066 %ZZ = call zeroext i32 @bar() ; Return value is %zero extended
11071 This is something we'd like to change in the future to provide better
11089 The '``va_arg``' instruction is used to access arguments passed through
11090 the "variable argument" area of a function call. It is used to implement
11099 type of ``va_list`` is target specific.
11109 It is legal for this instruction to be called in a function which does
11113 ``va_arg`` is an LLVM instruction instead of an :ref:`intrinsic
11123 types on any target.
11144 The '``landingpad``' instruction is used by `LLVM's exception handling
11146 is a landing pad --- one where the exception lands, and corresponds to the
11155 ``cleanup`` flag indicates that the landing pad block is a cleanup.
11172 represented in LLVM IR is target specific.
11177 When the call stack is being unwound due to an exception being thrown,
11178 the exception is compared against each ``clause`` in turn. If it doesn't
11179 match any of the clauses, and the ``cleanup`` flag is not set, then
11184 - A landing pad block is a basic block which is the unwind destination
11190 - A basic block that is not a landing pad block may not include a
11201 ;; A landing pad that is a cleanup.
11224 The '``catchpad``' instruction is used by `LLVM's exception handling
11238 requires to know if this is an appropriate handler for the exception. Control
11239 will transfer to the ``catchpad`` if this is the first appropriate handler for
11242 The ``resultval`` has the type :ref:`token <t_token>` and is used to match the
11249 When the call stack is being unwound due to an exception being thrown, the
11250 exception is compared against the ``args``. If it doesn't match, control will
11251 not reach the ``catchpad`` instruction. The representation of ``args`` is
11252 entirely target and personality function-specific.
11258 instructions is described in the
11263 it is undefined behavior to execute a :ref:`call <i_call>` or :ref:`invoke <i_invoke>`
11292 The '``cleanuppad``' instruction is used by `LLVM's exception handling
11294 is a cleanup block --- one where a personality routine attempts to
11299 The ``resultval`` has the type :ref:`token <t_token>` and is used to
11301 The ``parent`` argument is the token of the funclet that contains the
11302 ``cleanuppad`` instruction. If the ``cleanuppad`` is not inside a funclet,
11314 When the call stack is being unwound due to an exception being thrown,
11318 represented in LLVM IR is target specific.
11322 - A cleanup block is a basic block which is the unwind destination of
11328 - A basic block that is not a cleanup block may not include a
11333 it is undefined behavior to execute a :ref:`call <i_call>` or :ref:`invoke <i_invoke>`
11356 prefix is reserved in LLVM for intrinsic names; thus, function names may
11359 functions may only be used in call or invoke instructions: it is illegal
11361 intrinsic functions are part of the LLVM language, it is required if any
11367 different integer types, overloading is used commonly to allow an
11379 whose type is matched against another type do not. For example, the
11383 ``i29 @llvm.ctpop.i29(i29 %val)``. Only one type, the return type, is
11384 overloaded, and only one type suffix is required. Because the argument's
11385 type is matched against the return type, it does not require its own
11388 For target developers who are defining intrinsics for back-end code
11391 code generation. In such cases, the recommended approach for target
11392 maintainers when defining intrinsics is to create separate integer and
11394 codegen is required for ``llvm.target.foo(<4 x i32>)`` and
11395 ``llvm.target.foo(<4 x float>)`` then these should be split into
11406 Variable argument support is defined in LLVM with the
11411 All of these functions operate on arguments that use a target-specific
11413 does not define what this type is, so all transformations should be
11421 ; This struct is different for every platform. For most platforms,
11422 ; it is merely an i8*.
11425 ; For Unix x86_64 platforms, va_list is the following struct:
11473 The argument is a pointer to a ``va_list`` element to initialize.
11479 available in C. In a target-dependent way, it initializes the
11505 The argument is a pointer to a ``va_list`` to destroy.
11511 available in C. In a target-dependent way, it destroys the ``va_list``
11538 The first argument is a pointer to a ``va_list`` element to initialize.
11539 The second argument is a pointer to a ``va_list`` element to copy from.
11545 available in C. In a target-dependent way, it copies the source
11547 intrinsic is necessary because the `` llvm.va_start`` intrinsic may be
11556 intrinsics in a manner which is appropriate for the target collector.
11633 The second argument is the address to read from, which should be an
11634 address allocated from the garbage collector. The first object is a
11669 The first argument is the reference to store, the second is the start of
11670 the object to store it to, and the third is the address of the field of
11703 target-specific value indicating the return address of the current
11711 caller, etc. The argument is **required** to be a constant integer
11719 cannot be identified. The value returned by this intrinsic is likely to
11740 The '``llvm.addressofreturnaddress``' intrinsic returns a target-specific
11742 current function is stored.
11751 This intrinsic is only implemented for x86 and aarch64.
11772 Note this intrinsic is only verified on AArch64.
11788 target-specific frame pointer value for the specified stack frame.
11795 its caller, etc. The argument is **required** to be a constant integer
11803 cannot be identified. The value returned by this intrinsic is likely to
11827 live frame pointer to recover the address of the allocation. The offset is
11843 call frame that is currently live. The return value of '``llvm.localaddress``'
11844 is one way to produce such a value, but various runtimes also expose a suitable
11848 '``llvm.localescape``' to recover. It is zero-indexed.
11898 A call to '``llvm.read_volatile_register``' is assumed to have side-effects
11901 This is useful to implement named register global variables that need
11902 to always be mapped to a specific register, as is common practice on
11911 work is needed to support other registers and even more so, allocatable
11929 The '``llvm.stacksave``' intrinsic is used to remember the current state
11931 :ref:`llvm.stackrestore <int_stackrestore>`. This is useful for
11940 ``llvm.stackrestore`` intrinsic is executed with a value saved from
11961 The '``llvm.stackrestore``' intrinsic is used to restore the state of
11963 :ref:`llvm.stacksave <int_stacksave>` intrinsic executed. This is
11988 The '``llvm.get.dynamic.area.offset.*``' intrinsic family is used to
11993 pointer to the most recent dynamic alloca. This is useful, for example,
12003 recent dynamic alloca. For targets where stack grows upwards, the situation is a bit more
12012 must match the target's default address space's (address space 0) pointer type.
12027 The '``llvm.prefetch``' intrinsic is a hint to the code generator to
12028 insert a prefetch instruction if supported; otherwise, it is a noop.
12035 ``address`` is the address to be prefetched, ``rw`` is the specifier
12037 ``locality`` is a temporal locality specifier ranging from (0) - no
12039 specifies whether the prefetch is performed on the data (1) or
12064 The '``llvm.pcmarker``' intrinsic is a method to export a Program
12066 method is target specific, but it is expected that the marker will use
12069 optimizations. It is possible that the presence of a marker will inhibit
12070 optimizations. The intended use is to be inserted after optimizations to
12076 ``id`` is a numerical id identifying the marker.
12110 is lowered to a constant 0.
12112 Note that runtime support may be conditional on the privilege-level code is
12137 intrinsic is a nop. On platforms with non-coherent instruction and data
12138 cache (e.g. ARM, MIPS), the intrinsic is lowered either to appropriate
12142 The default behavior is to emit a call to ``__clear_cache`` from the run
12170 The first argument is a pointer to a global variable containing the
12174 The second argument is a hash value that can be used by the consumer
12176 the third is the number of counters associated with ``name``. It is an
12207 The '``llvm.instrprof.increment.step``' intrinsic is an extension to
12240 lowered by the ``-instrprof`` pass to find out the target values,
12246 The first argument is a pointer to a global variable containing the
12250 The second argument is a hash value that can be used by the consumer
12252 is an error if ``hash`` differs between two instances of
12255 The third argument is the value of the expression being profiled. The profiled
12257 fourth argument represents the kind of value profiling that is being done. The
12260 ``<include/llvm/ProfileData/InstrProf.h>`` header file. The last argument is the
12267 should be inserted for value profiling of target expressions. ``-instrprof``
12292 for the current thread. The exact semantics of this value are target
12294 in the middle. Depending on the target, this intrinsic may read a register,
12319 The '``llvm.call.preallocated.setup``' intrinsic returns a token which is
12335 is allowed, but not
12373 argument at the preallocated call. The type is used in the case that an
12377 It is undefined behavior if this is called with a token from an
12409 It is undefined behavior to call both a '``llvm.call.preallocated.teardown``'
12412 For example, if the stack is allocated for a preallocated call by a
12457 This is an overloaded intrinsic. You can use ``llvm.abs`` on any
12474 The first argument is the value for which the absolute value is to be returned.
12478 The second argument must be a constant and is a flag to indicate whether the
12479 result value of the '``llvm.abs``' intrinsic is a
12480 :ref:`poison value <poisonvalues>` if the argument is statically or dynamically
12487 argument or each element of a vector argument.". If the argument is ``INT_MIN``,
12488 then the result is also ``INT_MIN`` if ``is_int_min_poison == 0`` and
12498 This is an overloaded intrinsic. You can use ``@llvm.smax`` on any
12511 and ``%b`` at a given index is returned for that index.
12527 This is an overloaded intrinsic. You can use ``@llvm.smin`` on any
12540 and ``%b`` at a given index is returned for that index.
12556 This is an overloaded intrinsic. You can use ``@llvm.umax`` on any
12569 of ``%a`` and ``%b`` at a given index is returned for that index.
12585 This is an overloaded intrinsic. You can use ``@llvm.umin`` on any
12598 of ``%a`` and ``%b`` at a given index is returned for that index.
12616 This is an overloaded intrinsic. You can use ``llvm.memcpy`` on any
12640 The first argument is a pointer to the destination, the second is a
12641 pointer to the source. The third argument is an integer argument
12642 specifying the number of bytes to copy, and the fourth is a
12648 If the ``isvolatile`` parameter is ``true``, the ``llvm.memcpy`` call is
12649 a :ref:`volatile operation <volatile>`. The detailed access behavior is not
12650 very cleanly specified and it is unwise to depend on it.
12657 non-overlapping. It copies "len" bytes of memory over. If the argument is known
12661 If "len" is 0, the pointers may be NULL, dangling, ``undef``, or ``poison``
12664 make the behavior of this ``llvm.memcpy`` defined, otherwise the behavior is
12675 This is an overloaded intrinsic. You can use ``llvm.memcpy.inline`` on any
12700 The first argument is a pointer to the destination, the second is a
12701 pointer to the source. The third argument is a constant integer argument
12702 specifying the number of bytes to copy, and the fourth is a
12708 If the ``isvolatile`` parameter is ``true``, the ``llvm.memcpy.inline`` call is
12709 a :ref:`volatile operation <volatile>`. The detailed access behavior is not
12710 very cleanly specified and it is unwise to depend on it.
12717 overlap. It copies "len" bytes of memory over. If the argument is known
12721 If "len" is 0, the pointers may be NULL, dangling, ``undef``, or ``poison``
12724 The generated code is guaranteed not to call any external functions.
12734 This is an overloaded intrinsic. You can use llvm.memmove on any integer
12749 source location to the destination location. It is similar to the
12760 The first argument is a pointer to the destination, the second is a
12761 pointer to the source. The third argument is an integer argument
12762 specifying the number of bytes to copy, and the fourth is a
12768 If the ``isvolatile`` parameter is ``true``, the ``llvm.memmove`` call
12769 is a :ref:`volatile operation <volatile>`. The detailed access behavior is
12770 not very cleanly specified and it is unwise to depend on it.
12777 copies "len" bytes of memory over. If the argument is known to be
12781 If "len" is 0, the pointers may be NULL, dangling, ``undef``, or ``poison``
12784 make the behavior of this ``llvm.memmove`` defined, otherwise the behavior is
12795 This is an overloaded intrinsic. You can use llvm.memset on any integer
12819 The first argument is a pointer to the destination to fill, the second
12820 is the byte value with which to fill it, the third argument is an
12822 is a boolean indicating a volatile access.
12827 If the ``isvolatile`` parameter is ``true``, the ``llvm.memset`` call is
12828 a :ref:`volatile operation <volatile>`. The detailed access behavior is not
12829 very cleanly specified and it is unwise to depend on it.
12835 at the destination location. If the argument is known to be
12839 If "len" is 0, the pointer may be NULL, dangling, ``undef``, or ``poison``
12842 make the behavior of this ``llvm.memset`` defined, otherwise the behavior is
12851 This is an overloaded intrinsic. You can use ``llvm.sqrt`` on any
12889 This is an overloaded intrinsic. You can use ``llvm.powi`` on any
12906 multiplications is not defined. When a vector of floating-point type is
12912 The second argument is an integer power, and the first is a value to
12927 This is an overloaded intrinsic. You can use ``llvm.sin`` on any
12964 This is an overloaded intrinsic. You can use ``llvm.cos`` on any
13001 This is an overloaded intrinsic. You can use ``llvm.pow`` on any
13039 This is an overloaded intrinsic. You can use ``llvm.exp`` on any
13077 This is an overloaded intrinsic. You can use ``llvm.exp2`` on any
13115 This is an overloaded intrinsic. You can use ``llvm.log`` on any
13153 This is an overloaded intrinsic. You can use ``llvm.log10`` on any
13191 This is an overloaded intrinsic. You can use ``llvm.log2`` on any
13231 This is an overloaded intrinsic. You can use ``llvm.fma`` on any
13268 This is an overloaded intrinsic. You can use ``llvm.fabs`` on any
13304 This is an overloaded intrinsic. You can use ``llvm.minnum`` on any
13335 If either operand is a NaN, returns the other non-NaN operand. Returns
13336 NaN only if both operands are NaN. The returned NaN is always
13342 signaling and quiet NaN inputs. If a target's implementation follows
13343 the standard and returns a quiet NaN if either input is a signaling
13344 NaN, the intrinsic lowering is responsible for quieting the inputs to
13355 This is an overloaded intrinsic. You can use ``llvm.maxnum`` on any
13385 If either operand is a NaN, returns the other non-NaN operand. Returns
13386 NaN only if both operands are NaN. The returned NaN is always
13392 signaling and quiet NaN inputs. If a target's implementation follows
13393 the standard and returns a quiet NaN if either input is a signaling
13394 NaN, the intrinsic lowering is responsible for quieting the inputs to
13404 This is an overloaded intrinsic. You can use ``llvm.minimum`` on any
13431 If either operand is a NaN, returns NaN. Otherwise returns the lesser
13432 of the two arguments. -0.0 is considered to be less than +0.0 for this
13442 This is an overloaded intrinsic. You can use ``llvm.maximum`` on any
13469 If either operand is a NaN, returns NaN. Otherwise returns the greater
13470 of the two arguments. -0.0 is considered to be less than +0.0 for this
13480 This is an overloaded intrinsic. You can use ``llvm.copysign`` on any
13516 This is an overloaded intrinsic. You can use ``llvm.floor`` on any
13551 This is an overloaded intrinsic. You can use ``llvm.ceil`` on any
13586 This is an overloaded intrinsic. You can use ``llvm.trunc`` on any
13622 This is an overloaded intrinsic. You can use ``llvm.rint`` on any
13659 This is an overloaded intrinsic. You can use ``llvm.nearbyint`` on any
13695 This is an overloaded intrinsic. You can use ``llvm.round`` on any
13731 This is an overloaded intrinsic. You can use ``llvm.roundeven`` on any
13747 integer in floating-point format rounding halfway cases to even (that is, to the
13748 nearest value that is an even integer).
13769 This is an overloaded intrinsic. You can use ``llvm.lround`` on any
13796 The argument is a floating-point number and the return value is an integer
13811 This is an overloaded intrinsic. You can use ``llvm.llround`` on any
13831 The argument is a floating-point number and the return value is an integer
13846 This is an overloaded intrinsic. You can use ``llvm.lrint`` on any
13873 The argument is a floating-point number and the return value is an integer
13888 This is an overloaded intrinsic. You can use ``llvm.llrint`` on any
13908 The argument is a floating-point number and the return value is an integer
13929 This is an overloaded intrinsic function. You can use bitreverse on any
13942 The '``llvm.bitreverse``' family of intrinsics is used to reverse the
13952 basis and the element order is not affected.
13960 This is an overloaded intrinsic function. You can use bswap on any
13961 integer type that is an even number of bytes (i.e. BitWidth % 16 == 0).
13973 The '``llvm.bswap``' family of intrinsics is used to byte swap an integer
13988 operate on a per-element basis and the element order is not affected.
13996 This is an overloaded intrinsic. You can use llvm.ctpop on any integer
14018 The only argument is the value to be counted. The argument may be of any
14034 This is an overloaded intrinsic. You can use ``llvm.ctlz`` on any
14056 The first argument is the value to be counted. This argument may be of
14060 The second argument must be a constant and is a flag to indicate whether
14071 ``src == 0`` then the result is the size in bits of the type of ``src``
14081 This is an overloaded intrinsic. You can use ``llvm.cttz`` on any
14103 The first argument is the value to be counted. This argument may be of
14107 The second argument must be a constant and is a flag to indicate whether
14118 then the result is the size in bits of the type of ``src`` if
14130 This is an overloaded intrinsic. You can use ``llvm.fshl`` on any
14144 the first two values are concatenated as { %a : %b } (%a is the most significant
14145 bits of the wide value), the combined value is shifted left, and the most
14146 significant bits are extracted to produce a result that is the same size as the
14147 original arguments. If the first 2 arguments are identical, this is equivalent
14149 element of the vector. The shift argument is treated as an unsigned amount
14156 argument is the shift amount. The arguments may be any integer type or a
14176 This is an overloaded intrinsic. You can use ``llvm.fshr`` on any
14190 the first two values are concatenated as { %a : %b } (%a is the most significant
14191 bits of the wide value), the combined value is shifted right, and the least
14192 significant bits are extracted to produce a result that is the same size as the
14193 original arguments. If the first 2 arguments are identical, this is equivalent
14195 element of the vector. The shift argument is treated as an unsigned amount
14202 argument is the shift amount. The arguments may be any integer type or a
14223 arithmetic operation modulo 2\ :sup:`n`\ , where n is the bit width of
14225 returned by ``llvm.sadd.with.overflow.i32`` is always the same as the
14227 the ``add`` is *not* modified by an ``nsw`` or ``nuw`` flag.
14229 The second element of the result is an ``i1`` that is 1 if the
14232 any ``N`` larger than the operands' width, ``ext(A op B) to iN`` is
14233 not equal to ``(ext(A) to iN) op (ext(B) to iN)`` where ``ext`` is
14235 ``op`` is the underlying arithmetic operation.
14237 The behavior of these intrinsics is well-defined for all argument
14246 This is an overloaded intrinsic. You can use ``llvm.sadd.with.overflow``
14277 first element of which is the signed summation, and the second element
14278 of which is a bit specifying if the signed summation resulted in an
14297 This is an overloaded intrinsic. You can use ``llvm.uadd.with.overflow``
14328 first element of which is the sum, and the second element of which is a
14347 This is an overloaded intrinsic. You can use ``llvm.ssub.with.overflow``
14378 first element of which is the subtraction, and the second element of
14379 which is a bit specifying if the signed subtraction resulted in an
14398 This is an overloaded intrinsic. You can use ``llvm.usub.with.overflow``
14429 the first element of which is the subtraction, and the second element of
14430 which is a bit specifying if the unsigned subtraction resulted in an
14449 This is an overloaded intrinsic. You can use ``llvm.smul.with.overflow``
14480 the first element of which is the multiplication, and the second element
14481 of which is a bit specifying if the signed multiplication resulted in an
14500 This is an overloaded intrinsic. You can use ``llvm.umul.with.overflow``
14531 the first element of which is the multiplication, and the second
14532 element of which is a bit specifying if the unsigned multiplication
14548 Saturation arithmetic is a version of arithmetic in which operations are
14550 an operation is greater than the maximum value, the result is set (or
14551 "clamped") to this maximum. If it is below the minimum, it is clamped to this
14561 This is an overloaded intrinsic. You can use ``llvm.sadd.sat``
14587 The maximum value this operation can clamp to is the largest signed value
14588 representable by the bit width of the arguments. The minimum value is the
14609 This is an overloaded intrinsic. You can use ``llvm.uadd.sat``
14635 The maximum value this operation can clamp to is the largest unsigned value
14636 representable by the bit width of the arguments. Because this is an unsigned
14656 This is an overloaded intrinsic. You can use ``llvm.ssub.sat``
14682 The maximum value this operation can clamp to is the largest signed value
14683 representable by the bit width of the arguments. The minimum value is the
14704 This is an overloaded intrinsic. You can use ``llvm.usub.sat``
14730 The minimum value this operation can clamp to is 0, which is the smallest
14732 Because this is an unsigned operation, the result will never saturate towards
14751 This is an overloaded intrinsic. You can use ``llvm.sshl.sat``
14771 bit width, but they must have the same bit width. ``%a`` is the value to be
14772 shifted, and ``%b`` is the amount to shift by. If ``b`` is (statically or
14774 the result is a :ref:`poison value <poisonvalues>`. If the arguments are
14775 vectors, each vector element of ``a`` is shifted by the corresponding shift
14782 The maximum value this operation can clamp to is the largest signed value
14783 representable by the bit width of the arguments. The minimum value is the
14804 This is an overloaded intrinsic. You can use ``llvm.ushl.sat``
14824 bit width, but they must have the same bit width. ``%a`` is the value to be
14825 shifted, and ``%b`` is the amount to shift by. If ``b`` is (statically or
14827 the result is a :ref:`poison value <poisonvalues>`. If the arguments are
14828 vectors, each vector element of ``a`` is shifted by the corresponding shift
14834 The maximum value this operation can clamp to is the largest unsigned value
14852 The number of digits after the radix point is referred as the `scale`. These
14870 … %r = ashr i8 %mul, i8 %scale2 ; this is for a target rounding down towards negative infinity
14886 %r = sdiv i8 %a3, %b2 ; this is for a target rounding towards zero
14890 the provided scale, the result is rounded. Rounding is unspecified since
14891 preferred rounding may vary for different targets. Rounding is specified
14892 through a target hook. Different pipelines should legalize or optimize this
14893 using the rounding specified by this hook if it is provided. Operations like
14897 result. That is, the error between the returned result and the true result must
14907 This is an overloaded intrinsic. You can use ``llvm.smul.fix``
14941 value is rounded up or down to the closest representable value. The rounding
14942 direction is unspecified.
14944 It is undefined behavior if the result value does not fit within the range of
14967 This is an overloaded intrinsic. You can use ``llvm.umul.fix``
15001 value is rounded up or down to the closest representable value. The rounding
15002 direction is unspecified.
15004 It is undefined behavior if the result value does not fit within the range of
15026 This is an overloaded intrinsic. You can use ``llvm.smul.fix.sat``
15059 value is rounded up or down to the closest representable value. The rounding
15060 direction is unspecified.
15062 The maximum value this operation can clamp to is the largest signed value
15063 representable by the bit width of the first 2 arguments. The minimum value is the
15096 This is an overloaded intrinsic. You can use ``llvm.umul.fix.sat``
15129 value is rounded up or down to the closest representable value. The rounding
15130 direction is unspecified.
15132 The maximum value this operation can clamp to is the largest unsigned value
15133 representable by the bit width of the first 2 arguments. The minimum value is the
15163 This is an overloaded intrinsic. You can use ``llvm.sdiv.fix``
15197 value is rounded up or down to the closest representable value. The rounding
15198 direction is unspecified.
15200 It is undefined behavior if the result value does not fit within the range of
15201 the fixed point type, or if the second argument is zero.
15223 This is an overloaded intrinsic. You can use ``llvm.udiv.fix``
15257 value is rounded up or down to the closest representable value. The rounding
15258 direction is unspecified.
15260 It is undefined behavior if the result value does not fit within the range of
15261 the fixed point type, or if the second argument is zero.
15283 This is an overloaded intrinsic. You can use ``llvm.sdiv.fix.sat``
15316 value is rounded up or down to the closest representable value. The rounding
15317 direction is unspecified.
15319 The maximum value this operation can clamp to is the largest signed value
15320 representable by the bit width of the first 2 arguments. The minimum value is the
15323 It is undefined behavior if the second argument is zero.
15350 This is an overloaded intrinsic. You can use ``llvm.udiv.fix.sat``
15383 value is rounded up or down to the closest representable value. The rounding
15384 direction is unspecified.
15386 The maximum value this operation can clamp to is the largest unsigned value
15387 representable by the bit width of the first 2 arguments. The minimum value is the
15390 It is undefined behavior if the second argument is zero.
15427 encoding of a floating-point number. This canonicalization is useful for
15428 implementing certain numeric primitives such as frexp. The canonical encoding is
15458 -0.0 is also sufficient provided that the rounding mode is not -Infinity.
15460 ``@llvm.canonicalize`` must preserve the equality relation. That is:
15462 - ``(@llvm.canonicalize(x) == x)`` is equivalent to ``(x == x)``
15463 - ``(@llvm.canonicalize(x) == @llvm.canonicalize(y))`` is equivalent to
15476 - The input is known to be canonical. For example, it was produced by a
15477 floating-point operation that is required by the standard to be canonical.
15478 - The result is consumed only by (or fused with) other floating-point
15479 operations. That is, the bits of the floating-point value are not examined.
15497 target instruction set has support for a fused operation, and (b) that the
15498 fused operation is more efficient than the equivalent, separate pair of mul
15516 is equivalent to the expression a \* b + c, except that it is unspecified
15518 steps. Fusion is not guaranteed, even if the target platform supports it.
15519 If a fused multiply-add is required, the corresponding
15535 hints to the backend which are required to lower these intrinsics further to target
15536 specific instructions, or revert the hardware-loop to a normal loop if target
15550 This is an overloaded intrinsic.
15568 The integer operand is the loop trip count of the hardware-loop, and thus
15576 hardware-loop count with a target specific instruction, usually a move of this
15586 This is an overloaded intrinsic.
15600 preheader basic block and the output is expected to be the input to the
15607 The integer operand is the loop trip count of the hardware-loop, and thus
15615 hardware-loop count with a target specific instruction, usually a move of this
15624 This is an overloaded intrinsic.
15635 the loop trip count, and also test that the given count is not zero, allowing
15643 The integer operand is the loop trip count of the hardware-loop, and thus
15651 set up the hardware-loop count with a target specific instruction, usually a
15653 The result is the conditional value of whether the given count is not zero.
15661 This is an overloaded intrinsic.
15678 Both arguments must have identical integer types. The first operand is the
15679 loop iteration counter. The second operand is the maximum number of elements
15686 two operands, which is not allowed to wrap. They return the remaining number of
15689 optimisations are allowed to treat it is a ``SUB``, and it is supported by
15701 This is an overloaded intrinsic.
15716 This is emitted if the loop counter is not updated via a ``PHI`` node, which
15722 The integer argument is the loop decrement value used to decrement the loop
15730 should exit, this ``SUB`` is not allowed to wrap. The result is a condition
15731 that is used by the conditional branch controlling the loop.
15786 the associativity of a scalarized reduction. That is, the reduction begins with
15801 The first argument to this intrinsic is a scalar start value for the reduction.
15805 To ignore the start value, negative zero (``-0.0``) can be used, as it is
15860 the associativity of a scalarized reduction. That is, the reduction begins with
15875 The first argument to this intrinsic is a scalar start value for the reduction.
15879 To ignore the start value, one (``1.0``) can be used, as it is the neutral
16056 intrinsic. That is, the result will always be a number unless all elements of
16058 containing both +0.0 and -0.0 elements, the sign of the result is unspecified.
16072 This is an overloaded intrinsic.
16087 intrinsic. That is, the result will always be a number unless all elements of
16089 containing both +0.0 and -0.0 elements, the sign of the result is unspecified.
16103 This is an overloaded intrinsic. You can use ``llvm.experimental.vector.insert``
16123 The ``vec`` is the vector which ``subvec`` will be inserted into.
16124 The ``subvec`` is the vector that will be inserted.
16128 vector length. If ``subvec`` is a scalable vector, ``idx`` is first scaled by
16132 cannot be determined statically but is false at runtime, then the result vector
16133 is undefined.
16141 This is an overloaded intrinsic. You can use
16161 The ``vec`` is the vector from which we will extract a subvector.
16164 subvector is extracted. ``idx`` must be a constant multiple of the known-minimum
16165 vector length of the result type. If the result type is a scalable vector,
16166 ``idx`` is first scaled by the result type's runtime scaling factor. Elements
16168 indices. If this condition cannot be determined statically but is false at
16169 runtime, then the result vector is undefined. The ``idx`` parameter must be a
16180 ``C`` matrix, element ``i`` of column ``j`` is at index ``j * R + i`` in the
16182 is assumed. The intrinsics support both integer and floating point matrixes.
16190 This is an overloaded intrinsic.
16205 The first argument ``%In`` is a vector that corresponds to a ``<Rows> x
16216 This is an overloaded intrinsic.
16227 multiplies them. The result matrix is returned in the result vector.
16246 This is an overloaded intrinsic.
16259 ``<IsVolatile>`` is true, the intrinsic is considered a :ref:`volatile memory
16260 access <volatile>`. The result matrix is returned in the result vector. If the
16261 ``%Ptr`` argument is known to be aligned to some boundary, this can be
16267 The first argument ``%Ptr`` is a pointer type to the returned vector type, and
16269 is a positive, constant integer with ``%Stride >= <Rows>``. ``%Stride`` is used
16271 memory addresses is calculated with ``%Ptr + C * %Stride``. The third Argument
16272 ``<IsVolatile>`` is a boolean value. The fourth and fifth arguments,
16297 columns. If ``<IsVolatile>`` is true, the intrinsic is considered a
16300 If the ``%Ptr`` argument is known to be aligned to some boundary, this can be
16306 The first argument ``%In`` is a vector that corresponds to a ``<Rows> x
16307 <Cols>`` matrix to be stored to memory. The second argument ``%Ptr`` is a
16308 pointer to the vector type of ``%In``, and is the start address of the matrix
16309 in memory. The third argument ``%Stride`` is a positive, constant integer with
16310 ``%Stride >= <Rows>``. ``%Stride`` is used to compute the column memory
16311 addresses. I.e., for a column ``C``, its start memory addresses is calculated
16312 with ``%Ptr + C * %Stride``. The fourth argument ``<IsVolatile>`` is a boolean
16323 For most target platforms, half precision floating-point is a
16324 storage-only format. This means that it is a dense encoding (in memory)
16331 etc). To store the value back to memory, it is first converted to float
16366 return value is an ``i16`` which contains the converted number.
16407 precision floating-point format. The input half-float value is
16441 the :ref:`nest <nest>` attribute, from a function. The result is a
16443 not need to provide a value for it. Instead, the value to use is stored
16446 argument list. This is used to implement the GCC nested function address
16449 For example, if the function is ``i32 f(i8* nest %c, i32 %x, i32 %y)``
16461 The call ``%val = call i32 %fp(i32 %x, i32 %y)`` is then equivalent to
16487 sufficiently aligned block of memory; this memory is written to by the
16488 intrinsic. Note that the size and the alignment are target-specific -
16491 target-specific knowledge. The ``func`` argument must hold a function
16497 The block of memory pointed to by ``tramp`` is filled with target
16501 function's signature is the same as that of ``func`` with any arguments
16503 argument is allowed, and it must be of pointer type. Calling the new
16504 function is equivalent to calling ``func`` with the same argument list,
16506 calling ``llvm.init.trampoline``, the memory pointed to by ``tramp`` is
16508 pointer is undefined.
16539 different than the address where the trampoline is actually stored. This
16558 is an unsigned integer value. The explicit vector length parameter (%evl) is in
16563 0 <= %evl <= W, where W is the number of vector elements
16565 Note that for :ref:`scalable vector types <t_vector>` ``W`` is the runtime
16570 to True, and all other lanes ``%evl <= i < W`` to False. A new mask %M is
16588 The use of an effective %evl is discouraged for those targets. The function
16589 ``TargetTransformInfo::hasActiveVectorLength()`` returns true when the target
16600 This is an overloaded intrinsic.
16618 third operand is the vector mask and has the same number of elements as the
16619 result vector type. The fourth operand is the explicit vector length of the
16627 disabled lanes is undefined.
16635 ;; For all lanes below %evl, %r is lane-wise equivalent to %also.r
16647 This is an overloaded intrinsic.
16665 third operand is the vector mask and has the same number of elements as the
16666 result vector type. The fourth operand is the explicit vector length of the
16674 lane. The result on disabled lanes is undefined.
16682 ;; For all lanes below %evl, %r is lane-wise equivalent to %also.r
16696 This is an overloaded intrinsic.
16714 third operand is the vector mask and has the same number of elements as the
16715 result vector type. The fourth operand is the explicit vector length of the
16722 lane. The result on disabled lanes is undefined.
16730 ;; For all lanes below %evl, %r is lane-wise equivalent to %also.r
16743 This is an overloaded intrinsic.
16761 third operand is the vector mask and has the same number of elements as the
16762 result vector type. The fourth operand is the explicit vector length of the
16770 disabled lanes is undefined.
16778 ;; For all lanes below %evl, %r is lane-wise equivalent to %also.r
16791 This is an overloaded intrinsic.
16808 … type. The third operand is the vector mask and has the same number of elements as the result vect…
16815 lane. The result on disabled lanes is undefined.
16823 ;; For all lanes below %evl, %r is lane-wise equivalent to %also.r
16837 This is an overloaded intrinsic.
16855 third operand is the vector mask and has the same number of elements as the
16856 result vector type. The fourth operand is the explicit vector length of the
16864 lane. The result on disabled lanes is undefined.
16872 ;; For all lanes below %evl, %r is lane-wise equivalent to %also.r
16886 This is an overloaded intrinsic.
16904 third operand is the vector mask and has the same number of elements as the
16905 result vector type. The fourth operand is the explicit vector length of the
16913 lane. The result on disabled lanes is undefined.
16921 ;; For all lanes below %evl, %r is lane-wise equivalent to %also.r
16934 This is an overloaded intrinsic.
16952 third operand is the vector mask and has the same number of elements as the
16953 result vector type. The fourth operand is the explicit vector length of the
16961 enabled lane. The result on disabled lanes is undefined.
16969 ;; For all lanes below %evl, %r is lane-wise equivalent to %also.r
16983 This is an overloaded intrinsic.
17001 third operand is the vector mask and has the same number of elements as the
17002 result vector type. The fourth operand is the explicit vector length of the
17010 enabled lane. The result on disabled lanes is undefined.
17018 ;; For all lanes below %evl, %r is lane-wise equivalent to %also.r
17031 This is an overloaded intrinsic.
17049 third operand is the vector mask and has the same number of elements as the
17050 result vector type. The fourth operand is the explicit vector length of the
17058 disabled lanes is undefined.
17066 ;; For all lanes below %evl, %r is lane-wise equivalent to %also.r
17079 This is an overloaded intrinsic.
17097 third operand is the vector mask and has the same number of elements as the
17098 result vector type. The fourth operand is the explicit vector length of the
17105 first two operands on each enabled lane. The result on disabled lanes is
17114 ;; For all lanes below %evl, %r is lane-wise equivalent to %also.r
17127 This is an overloaded intrinsic.
17145 third operand is the vector mask and has the same number of elements as the
17146 result vector type. The fourth operand is the explicit vector length of the
17153 the first two operands on each enabled lane. The result on disabled lanes is
17162 ;; For all lanes below %evl, %r is lane-wise equivalent to %also.r
17175 This is an overloaded intrinsic.
17193 third operand is the vector mask and has the same number of elements as the
17194 result vector type. The fourth operand is the explicit vector length of the
17202 The result on disabled lanes is undefined.
17210 ;; For all lanes below %evl, %r is lane-wise equivalent to %also.r
17223 This is an overloaded intrinsic.
17242 Both operands have the same scalar integer type. The result is a vector with
17255 where ``%m`` is a vector (mask) of active/inactive lanes with its elements
17257 ``llvm.get.active.lane.mask.*``, ``%icmp`` is an integer compare and ``ult``
17259 ``(%base + i)`` and its comparison against ``%n`` as it is performed in integer
17260 numbers and not in machine numbers. If ``%n`` is ``0``, then the result is a
17261 poison value. The above is equivalent to:
17268 ``%base`` is the first element of the vector induction variable (VIV) and
17269 ``%n`` is the loop tripcount. Thus, these intrinsics perform an element-wise
17274 it is unknown what the type of the step vector needs to be that enumerate its
17279 back-edge taken count of the original scalar loop is explicit as the second
17297 …is specified by a mask operand, which holds one bit per vector element, switching the associated v…
17306 This is an overloaded intrinsic. The loaded data is a vector of any integer, floating-point or poin…
17312 ;; The data is a vector of pointers to double
17314 ;; The data is a vector of function pointers
17320 …rding to the provided mask. The mask holds a bit for each vector lane, and is used to prevent memo…
17326 …is the base pointer for the load. The second operand is the alignment of the source location. It m…
17331 …lvm.masked.load``' intrinsic is designed for conditional reading of selected vector elements in a …
17332 The result of this operation is equivalent to a regular vector load instruction followed by a 'sele…
17339 …;; The result of the two following instructions is identical aside from potential memory access ex…
17350 This is an overloaded intrinsic. The data stored in memory is a vector of any integer, floating-poi…
17356 ;; The data is a vector of pointers to double
17358 ;; The data is a vector of function pointers
17364 …rding to the provided mask. The mask holds a bit for each vector lane, and is used to prevent memo…
17369 …is the vector value to be written to memory. The second operand is the base pointer for the store,…
17375 …m.masked.store``' intrinsics is designed for conditional writing of selected vector elements in a …
17376 The result of this operation is equivalent to a load-modify-store sequence. However, using this int…
17382 …;; The result of the following instructions is identical aside from potential data races and memor…
17391 …es corresponding to the "off" lanes are not accessed. When all bits are off, no memory is accessed.
17400 This is an overloaded intrinsic. The loaded data are multiple scalar values of any integer, floatin…
17411 …inters '``ptrs``'. The memory is accessed according to the provided mask. The mask holds a bit for…
17417 …is a vector of pointers which holds all memory addresses to read. The second operand is an alignme…
17422 …``' intrinsic is designed for conditional reading of multiple scalar values from arbitrary memory …
17430 ;; The gather with all-true mask is equivalent to the following instruction sequence
17453 …is an overloaded intrinsic. The data stored in memory is a vector of any integer, floating-point o…
17464 …s a vector of pointers. Writing is done according to the provided mask. The mask holds a bit for e…
17469 …is a vector value to be written to memory. The second operand is a vector of pointers, pointing to…
17474 …is designed for writing selected vector elements to arbitrary memory addresses in a single IR oper…
17481 ;; It is equivalent to a list of scalar stores
17490 ;; Note: the order of the following stores is important when they overlap:
17500 …rding to a mask is stored in consecutive memory addresses (compressed store), and vice-versa (expa…
17509 This is an overloaded intrinsic. Several values of integer, floating point or pointer data type are…
17519 …is equal to the number of '1' bits in the mask. The loaded elements are positioned in the destinat…
17525 …is the base pointer for the load. It has the same underlying type as the element of the returned v…
17530 …``' intrinsic is designed for reading multiple scalar values from adjacent memory addresses into p…
17545 ; The number of loaded elements is equal to the number of '1' elements in the Mask.
17558 If all mask elements are '1', the intrinsic behavior is equivalent to the regular unmasked vector l…
17567 This is an overloaded intrinsic. A number of scalar values of integer, floating point or pointer da…
17577 …olds a bit for each vector lane, and is used to select elements to be stored. The number of elemen…
17582 …is the input vector, from which elements are collected and written to memory. The second operand i…
17588 …is designed for compressing data in memory. It allows to collect elements from possibly non-adjace…
17644 The first argument is a constant integer representing the size of the
17645 object, or -1 if it is variable sized. The second argument is a pointer
17652 of the memory pointed to by ``ptr`` is dead. This means that it is known
17677 The first argument is a constant integer representing the size of the
17678 object, or -1 if it is variable sized. The second argument is a pointer
17685 the memory pointed to by ``ptr`` is dead. This means that it is known to
17694 This is an overloaded intrinsic. The memory object can belong to any address space.
17709 The first argument is a constant integer representing the size of the
17710 object, or -1 if it is variable sized. The second argument is a pointer
17717 the return value, the referenced memory location is constant and
17725 This is an overloaded intrinsic. The memory object can belong to any address space.
17740 The first argument is the matching ``llvm.invariant.start`` intrinsic.
17741 The second argument is a constant integer representing the size of the
17742 object, or -1 if it is variable sized and the third argument is a
17748 This intrinsic indicates that the memory is mutable again.
17755 This is an overloaded intrinsic. The memory object can belong to any address
17768 pointer value that carries fresh invariant group information. It is an
17776 The ``llvm.launder.invariant.group`` takes only one argument, which is a pointer
17782 Returns another pointer that aliases its argument but which is considered different
17791 This is an overloaded intrinsic. The memory object can belong to any address
17804 value that does not carry the invariant information. It is an experimental
17811 The ``llvm.strip.invariant.group`` takes only one argument, which is a pointer
17829 operations when specific rounding mode or floating-point exception behavior is
17830 required. By default, LLVM optimization passes assume that the rounding mode is
17834 optimize FP code when the default behavior is used.
17836 If any FP operation in a function is constrained then they all must be
17837 constrained. This is required for correct LLVM IR. Optimizations that
17839 operations is done. The correct way to mix constrained and less constrained
17840 operations is to use the rounding mode and exception handling metadata to
17847 The rounding mode argument is a metadata string specifying what
17861 If this argument is "round.dynamic" optimization passes must assume that the
17862 rounding mode is unknown and may change at runtime. No transformations that
17866 similarly named IEEE rounding modes. If the argument is any of these values
17870 For example, 'x-0'->'x' is not a valid transformation if the rounding mode is
17871 "round.downward" or "round.dynamic" because if the value of 'x' is +0 then
17873 transformation is legal for all other rounding modes.
17876 actual runtime rounding mode (as defined in a target-specific manner) matches
17877 the specified rounding mode, but this is not guaranteed. Using a specific
17881 The exception behavior argument is a metadata string describing the floating
17891 If this argument is "fpexcept.ignore" optimization passes may assume that the
17898 If the exception behavior argument is "fpexcept.maytrap" optimization passes
17905 If the exception behavior argument is "fpexcept.strict" all transformations must
17909 exceptions that would not have been raised by the original code. This is the
17914 The number and order of floating-point exceptions is NOT guaranteed. For
17919 Proper :ref:`function attributes <fnattrs>` usage is required for the
17961 The value produced is the floating-point sum of the two value operands and has
17998 The value produced is the floating-point difference of the two value operands
18035 The value produced is the floating-point product of the two value operands and
18072 The value produced is the floating-point quotient of the two value operands and
18105 the result of frem is never rounded, but the argument is included for
18111 The value produced is the floating-point remainder from the division of the two
18147 The result produced is the product of the first two operands added to the third
18148 operand computed with infinite precision, and then rounded to the target
18181 The result produced is an unsigned integer converted from the floating
18182 point operand. The value is truncated, so it is rounded towards zero.
18214 The result produced is a signed integer converted from the floating
18215 point operand. The value is truncated, so it is rounded towards zero.
18249 An inexact floating-point exception will be raised if rounding is required.
18250 Any result produced is a floating point value converted from the input
18285 An inexact floating-point exception will be raised if rounding is required.
18286 Any result produced is a floating point value converted from the input
18322 The result produced is a floating point value truncated to be smaller in size
18356 The result produced is a floating point value extended to be larger in size
18384 If the operands are floating-point scalars, then the result type is a
18387 If the operands are floating-point vectors, then the result type is a
18403 The third argument is the condition code indicating the kind of comparison
18421 *Ordered* means that neither operand is a NAN while *unordered* means
18435 is equal to ``op2``.
18437 is greater than ``op2``.
18439 is greater than or equal to ``op2``.
18441 is less than ``op2``.
18443 is less than or equal to ``op2``.
18445 is not equal to ``op2``.
18447 - "``ueq``": yields ``true`` if either operand is a NAN or ``op1`` is
18449 - "``ugt``": yields ``true`` if either operand is a NAN or ``op1`` is
18451 - "``uge``": yields ``true`` if either operand is a NAN or ``op1`` is
18453 - "``ult``": yields ``true`` if either operand is a NAN or ``op1`` is
18455 - "``ule``": yields ``true`` if either operand is a NAN or ``op1`` is
18457 - "``une``": yields ``true`` if either operand is a NAN or ``op1`` is
18459 - "``uno``": yields ``true`` if either operand is a NAN.
18463 if either operand is a SNAN. The signaling comparison operation
18465 exception if either operand is a NAN (QNAN or SNAN).
18486 that (a) the target instruction set has support for a fused operation,
18487 and (b) that the fused operation is more efficient than the equivalent,
18511 is equivalent to the expression:
18522 except that it is unspecified whether rounding will be performed between the
18523 multiplication and addition steps. Fusion is not guaranteed, even if the target
18525 If a fused multiply-add is required, the corresponding
18577 If the value is less than negative zero, a floating-point exception occurs
18578 and the return value is architecture specific.
18636 order of evaluation of multiplications is not defined. When a vector of
18637 floating-point type is used, the second argument remains a scalar integer value.
18644 type. The second argument is a 32-bit signed integer specifying the power to
18924 exception if the operand is not an integer.
18939 would, and handles error conditions in the same way. The rounding mode is
18941 mode is determined by the runtime floating-point environment. The rounding
18942 mode argument is only intended as information to the compiler.
18963 will be raised if the operand is not an integer. An invalid exception is
18964 raised if the result is too large to fit into a supported integer type,
18965 and in this case the result is undefined.
18970 The first argument is a floating-point number. The return value is an
18984 The rounding mode is described, not determined, by the rounding mode
18985 argument. The actual rounding mode is determined by the runtime floating-point
18986 environment. The rounding mode argument is only intended as information
18989 If the runtime floating-point environment is using the default rounding mode
19011 will be raised if the operand is not an integer. An invalid exception is
19012 raised if the result is too large to fit into a supported integer type,
19013 and in this case the result is undefined.
19018 The first argument is a floating-point number. The return value is an
19032 The rounding mode is described, not determined, by the rounding mode
19033 argument. The actual rounding mode is determined by the runtime floating-point
19034 environment. The rounding mode argument is only intended as information
19037 If the runtime floating-point environment is using the default rounding mode
19059 floating-point exception if the operand is not an integer.
19075 would, and handles error conditions in the same way. The rounding mode is
19077 mode is determined by the runtime floating-point environment. The rounding
19078 mode argument is only intended as information to the compiler.
19325 halfway cases to even (that is, to the nearest value that is an even integer),
19361 raise an inexact floating-point exception if the operand is not an integer.
19362 An invalid exception is raised if the result is too large to fit into a
19363 supported integer type, and in this case the result is undefined.
19368 The first argument is a floating-point number. The return value is an
19399 raise an inexact floating-point exception if the operand is not an integer.
19400 An invalid exception is raised if the result is too large to fit into a
19401 supported integer type, and in this case the result is undefined.
19406 The first argument is a floating-point number. The return value is an
19480 Encoding of the returned values is same as the result of ``FLT_ROUNDS``,
19492 target. These values are target-specific.
19497 This class of intrinsics is designed to be generic and has no specific
19518 The first argument is a pointer to a value, the second is a pointer to a
19519 global string, the third is a pointer to a global string which is the
19520 source file name, and the last argument is the line number.
19536 This is an overloaded intrinsic. You can use '``llvm.ptr.annotation``' on a
19538 the pointer. The identifier for the default address space is the integer
19557 The first argument is a pointer to an integer value of arbitrary bitwidth
19558 (result of some expression), the second is a pointer to a global string, the
19559 third is a pointer to a global string which is the source file name, and the
19560 last argument is the line number. It returns the value of the first argument.
19576 This is an overloaded intrinsic. You can use '``llvm.annotation``' on
19595 The first argument is an integer value (result of some expression), the
19596 second is a pointer to a global string, the third is a pointer to a
19597 global string which is the source file name, and the last argument is
19615 ``S_ANNOTATION`` codeview record with some additional string metadata. This is
19616 used to implement MSVC's ``__annotation`` intrinsic. It is marked
19652 This intrinsic is lowered to the target dependent trap instruction. If
19653 the target does not have a trap instruction, this intrinsic will be
19679 This intrinsic is lowered to code which is intended to cause an
19706 This intrinsic is lowered to code which is intended to cause an execution trap,
19726 onto the stack at ``slot``. The stack slot is adjusted to ensure that it
19727 is placed on the stack before local variables.
19733 The first argument is the value loaded from the stack guard
19734 ``@__stack_chk_guard``. The second variable is an ``alloca`` that has
19741 the ``AllocaInst`` stack slot to be before local variables on the stack. This is
19742 to ensure that if a local variable on the stack is overwritten, it will destroy
19743 the value of the guard. When the function exits, the guard on the stack is
19763 It should not be generated by frontends, since it is only for internal usage.
19764 The reason why we create this intrinsic is that we still support IR form Stack
19780 X86 Linux) that is not handled by ``llvm.stackguard()``, while they should be
19797 The ``llvm.objectsize`` intrinsic is designed to provide information to the
19806 The ``llvm.objectsize`` intrinsic takes four arguments. The first argument is a
19808 ``llvm.objectsize`` returns 0 (if true) or -1 (if false) when the object size is
19810 in address space 0 is used as its pointer argument. If it's ``false``,
19812 the ``null`` is in a non-zero address space or if ``true`` is given for the
19813 third argument of ``llvm.objectsize``, we assume its size is unknown. The fourth
19822 The ``llvm.objectsize`` intrinsic is lowered to a value representing the size of
19832 This is an overloaded intrinsic. You can use ``llvm.expect`` on any
19850 The ``llvm.expect`` intrinsic takes two arguments. The first argument is
19851 a value. The second argument is an expected value.
19856 This intrinsic is lowered to the ``val``.
19864 This intrinsic is similar to ``llvm.expect``. This is an overloaded intrinsic.
19884 argument is a value. The second argument is an expected value. The third
19885 argument is a probability.
19890 This intrinsic is lowered to the ``val``.
19908 condition is true. This information can then be used in simplifying other parts
19917 The argument of the call is the condition which the optimizer may assume is
19923 The intrinsic allows the optimizer to assume that the provided condition is
19924 always true whenever the control flow reaches the intrinsic call. No code is
19926 provided condition are not used for code generation. If the condition is
19927 violated during execution, the behavior is undefined.
19953 The first argument is an operand which is used as the returned value.
19962 uses. It is not meant for general use, only for building temporary
19981 The first argument is a pointer to be tested. The second argument is a
19987 The ``llvm.type.test`` intrinsic tests whether the given pointer is associated
20006 The first argument is a pointer from which to load a function pointer. The
20007 second argument is the byte offset from which to load the function pointer. The
20008 third argument is a metadata object representing a :doc:`type identifier
20015 virtual table pointer using type metadata. This intrinsic is used to implement
20019 check in cases where it is not needed to enforce the control flow integrity
20022 If the given pointer is associated with a type metadata identifier, this
20024 the function may also return true if the given pointer is not associated
20026 element is true, the following rules apply to the first element:
20028 - If the given pointer is associated with the given type metadata identifier,
20029 it is the function pointer loaded from the given byte offset from the given
20032 - If the given pointer is not associated with the given type metadata
20033 identifier, it is one of the following (the choice of which is unspecified):
20042 If the function's return value's second element is false, the value of the
20043 first element is undefined.
20103 The intrinsic takes an arbitrary number of arguments, whose meaning is
20113 the continuation itself is out of scope of the language reference --
20114 as far as LLVM is concerned, the deoptimization continuation can
20125 ``@llvm.experimental.deoptimize`` call if there is one, or void.
20144 symbol ``__llvm_deoptimize`` (it is the frontend's responsibility to
20145 ensure that this symbol is defined). The call arguments to
20166 ``@llvm.experimental.guard`` is defined in terms of
20167 ``@llvm.experimental.deoptimize`` -- its body is defined to be
20186 is present on the call site. For more details on ``!make.implicit``,
20191 is ``false``. Since the optimizer is allowed to replace the ``undef``
20200 Support for ``@llvm.experimental.guard`` is slowly being rephrased in
20216 This intrinsic represents a "widenable condition" which is
20218 expression is `true` or `false`, the program is correct and
20227 While this may appear similar in semantics to `undef`, it is very
20229 value. It is also intended to be lowered late, and remain available
20246 with either value whenever one is beneficial.
20263 Whether the result of intrinsic's call is `true` or `false`,
20269 This is how it can be used to represent guards as widenable branches:
20295 So the block `guarded` is only reachable when `%cond` is `true`,
20297 is `true` or `false`.
20305 When ``@llvm.experimental.widenable.condition()`` is used in
20306 condition of a guard represented as explicit branch, it is
20327 for this branch. Here `%any_other_cond` is an arbitrarily chosen
20330 deopt when the new condition is not met.
20335 Default lowering strategy is replacing the result of
20337 constant `true`. However it is always correct to replace
20358 load from; if a loaded constant initializer is known to have the form
20359 ``i32 trunc(x - %ptr)``, the intrinsic call is folded to ``x``.
20362 not overflow at link time under the medium code model if ``x`` is an
20399 '``llvm.is.constant.*``' Intrinsic
20405 This is an overloaded intrinsic. You can use llvm.is.constant with any argument type.
20409 declare i1 @llvm.is.constant.i32(i32 %operand) nounwind readnone
20410 declare i1 @llvm.is.constant.f32(float %operand) nounwind readnone
20411 declare i1 @llvm.is.constant.TYPENAME(TYPE %operand) nounwind readnone
20416 The '``llvm.is.constant``' intrinsic will return true if the argument
20417 is known to be a manifest compile-time constant. It is guaranteed to
20423 This intrinsic generates no code. If its argument is known to be a
20428 In particular, note that if the argument is a constant expression
20437 ``llvm.is.constant.i32(i32 %param)`` *can* return true after the
20438 function is inlined, if the value passed to the function parameter was
20441 On the other hand, if constant folding is not run, it will never
20459 The first argument is a pointer. The second argument is an integer.
20472 The result of ``ptrmask(ptr, mask)`` is equivalent to
20477 mask argument does not match the pointer size of the target, the mask is
20502 ``vscale`` is a positive value that is constant throughout program
20503 execution, but is unknown at compile time.
20504 If the result value does not fit in the result type, then the result is
20529 This is an overloaded intrinsic. You can use ``llvm.memcpy.element.unordered.atomic`` on
20547 The '``llvm.memcpy.element.unordered.atomic.*``' intrinsic is a specialization of the
20557 intrinsic, with the added constraint that ``len`` is required to be a positive integer
20558 multiple of the ``element_size``. If ``len`` is not a positive integer multiple of
20559 ``element_size``, then the behaviour of the intrinsic is undefined.
20562 target-specific atomic access size limit.
20573 allowed to overlap. The memory copy is performed as a sequence of load/store operations
20574 where each access is guaranteed to be a multiple of ``element_size`` bytes wide and
20577 The order of the copy is unspecified. The same value may be read from the source
20578 buffer many times, but only one write is issued to the destination buffer per
20579 element. It is well defined to have concurrent reads and writes to both source and
20589 In the most general case call to the '``llvm.memcpy.element.unordered.atomic.*``' is
20591 is replaced with an actual element size. See :ref:`RewriteStatepointsForGC intrinsic
20595 Optimizer is allowed to inline memory copy when it's profitable to do so.
20603 This is an overloaded intrinsic. You can use
20621 The '``llvm.memmove.element.unordered.atomic.*``' intrinsic is a specialization
20633 ``len`` is required to be a positive integer multiple of the ``element_size``.
20634 If ``len`` is not a positive integer multiple of ``element_size``, then the
20635 behaviour of the intrinsic is undefined.
20638 greater than a target-specific atomic access size limit.
20650 are allowed to overlap. The memory copy is performed as a sequence of load/store
20651 operations where each access is guaranteed to be a multiple of ``element_size``
20654 The order of the copy is unspecified. The same value may be read from the source
20655 buffer many times, but only one write is issued to the destination buffer per
20656 element. It is well defined to have concurrent reads and writes to both source
20668 '``llvm.memmove.element.unordered.atomic.*``' is lowered to a call to the symbol
20669 ``__llvm_memmove_element_unordered_atomic_*``. Where '*' is replaced with an
20674 The optimizer is allowed to inline the memory copy when it's profitable to do so.
20684 This is an overloaded intrinsic. You can use ``llvm.memset.element.unordered.atomic`` on
20702 The '``llvm.memset.element.unordered.atomic.*``' intrinsic is a specialization of the
20703 '``llvm.memset.*``' intrinsic. It differs in that the ``dest`` is treated as an array
20712 intrinsic, with the added constraint that ``len`` is required to be a positive integer
20713 multiple of the ``element_size``. If ``len`` is not a positive integer multiple of
20714 ``element_size``, then the behaviour of the intrinsic is undefined.
20717 target-specific atomic access size limit.
20721 the destination pointer is aligned to that boundary.
20727 memory starting at the destination location to the given ``value``. The memory is
20728 set with a sequence of store operations where each access is guaranteed to be a
20731 The order of the assignment is unspecified. Only one write is issued to the
20732 destination buffer per element. It is well defined to have concurrent reads and
20742 In the most general case call to the '``llvm.memset.element.unordered.atomic.*``' is
20744 is replaced with an actual element size.
20746 The optimizer is allowed to inline the memory assignment when it's profitable to do so.
20752 LLVM is aware of the semantics of these functions, and optimizes based on that
21035 into the array. The return type ``ret_type`` is a pointer type to the array element.
21036 The array ``dim`` and ``index`` are preserved which is more robust than
21038 The ``llvm.preserve.access.index`` type of metadata is attached to this call instruction
21040 The metadata is a ``DICompositeType`` or ``DIDerivedType`` representing the
21046 The ``base`` is the array base address. The ``dim`` is the array dimension.
21047 The ``base`` is a pointer if ``dim`` equals 0.
21048 The ``index`` is the last access index into the array or pointer.
21072 The ``llvm.preserve.access.index`` type of metadata is attached to this call instruction
21074 The metadata is a ``DICompositeType`` representing the debuginfo version of ``type``.
21075 The return type ``type`` is the same as the ``base`` type.
21080 The ``base`` is the union base address. The ``di_index`` is the field index in debuginfo.
21104 The ``llvm.preserve.access.index`` type of metadata is attached to this call instruction
21106 The metadata is a ``DICompositeType`` representing the debuginfo version of ``type``.
21107 The return type ``ret_type`` is a pointer type to the structure member.
21112 The ``base`` is the structure base address. The ``gep_index`` is the struct member index
21113 based on IR structures. The ``di_index`` is the struct member index based on debuginfo.