#. Named values are represented as a string of characters with their
prefix. For example, ``%foo``, ``@DivisionByZero``,
``%a.really.long.identifier``. The actual regular expression used is
- '``[%@][a-zA-Z$._][a-zA-Z$._0-9]*``'. Identifiers which require other
+ '``[%@][-a-zA-Z$._][-a-zA-Z$._0-9]*``'. Identifiers that require other
characters in their names can be surrounded with quotes. Special
characters may be escaped using ``"\xx"`` where ``xx`` is the ASCII
code for the character in hexadecimal. In this way, any character can
- be used in a name value, even quotes themselves.
+ be used in a name value, even quotes themselves. The ``"\01"`` prefix
+ can be used on global variables to suppress mangling.
#. Unnamed values are represented as an unsigned numeric value with
their prefix. For example, ``%12``, ``@2``, ``%44``.
#. Constants, which are described in the section Constants_ below.
#. Unnamed temporaries are created when the result of a computation is
not assigned to a named value.
#. Unnamed temporaries are numbered sequentially (using a per-function
- incrementing counter, starting with 0). Note that basic blocks are
- included in this numbering. For example, if the entry basic block is not
- given a label name, then it will get number 0.
+ incrementing counter, starting with 0). Note that basic blocks and unnamed
+ function parameters are included in this numbering. For example, if the
+ entry basic block is not given a label name and all function parameters are
+ named, then it will get number 0.
It also shows a convention that we follow in this document. When
demonstrating instructions, we will follow an instruction with a comment
; Definition of main function
define i32 @main() { ; i32()*
; Convert [13 x i8]* to i8 *...
- %cast210 = getelementptr [13 x i8]* @.str, i64 0, i64 0
+ %cast210 = getelementptr [13 x i8], [13 x i8]* @.str, i64 0, i64 0
; Call puts function to write out the string to stdout.
call i32 @puts(i8* %cast210)
}
; Named metadata
- !1 = metadata !{i32 42}
- !foo = !{!1, null}
+ !0 = !{i32 42, null, !"string"}
+ !foo = !{!0}
This example is made up of a :ref:`global variable <globalvars>` named
"``.str``", an external declaration of the "``puts``" function, a
"``anyregcc``" - Dynamic calling convention for code patching
This is a special convention that supports patching an arbitrary code
sequence in place of a call site. This convention forces the call
- arguments into registers but allows them to be dynamcially
+ arguments into registers but allows them to be dynamically
allocated. This can currently only be used with calls to
llvm.experimental.patchpoint because only this intrinsic records
the location of its arguments in a side table. See :doc:`StackMaps`.
"``preserve_mostcc``" - The `PreserveMost` calling convention
- This calling convention attempts to make the code in the caller as little
- intrusive as possible. This calling convention behaves identical to the `C`
+ This calling convention attempts to make the code in the caller as
+ unintrusive as possible. This convention behaves identically to the `C`
calling convention on how arguments and return values are passed, but it
uses a different set of caller/callee-saved registers. This alleviates the
burden of saving and recovering a large register set before and after the
The idea behind this convention is to support calls to runtime functions
that have a hot path and a cold path. The hot path is usually a small piece
- of code that doesn't many registers. The cold path might need to call out to
+ of code that doesn't use many registers. The cold path might need to call out to
another function and therefore only needs to preserve the caller-saved
registers, which haven't already been saved by the caller. The
`PreserveMost` calling convention is very similar to the `cold` calling
LLVM IR allows you to specify both "identified" and "literal" :ref:`structure
types <t_struct>`. Literal types are uniqued structurally, but identified types
are never uniqued. An :ref:`opaque structural type <t_opaque>` can also be used
-to forward declare a type which is not yet available.
+to forward declare a type that is not yet available.
An example of a identified structure specification is:
Global variables define regions of memory allocated at compilation time
instead of run-time.
-Global variables definitions must be initialized.
+Global variable definitions must be initialized.
Global variables in other translation units can also be declared, in which
case they don't have an initializer.
case, the extra alignment could be observable: for example, code could
assume that the globals are densely packed in their section and try to
iterate over them as an array, alignment padding would break this
-iteration.
+iteration. The maximum alignment is ``1 << 29``.
Globals can also have a :ref:`DLL storage class <dllstorageclass>`.
-Variables and aliasaes can have a
+Variables and aliases can have a
:ref:`Thread Local Storage Model <tls_model>`.
Syntax::
[@<GlobalVarName> =] [Linkage] [Visibility] [DLLStorageClass] [ThreadLocal]
[unnamed_addr] [AddrSpace] [ExternallyInitialized]
<global | constant> <Type> [<InitializerConstant>]
- [, section "name"] [, align <Alignment>]
+ [, section "name"] [, comdat [($name)]]
+ [, align <Alignment>]
For example, the following defines a global in a numbered address space
with an initializer, section, and alignment:
attributes <paramattrs>`), optional :ref:`function attributes <fnattrs>`,
an optional section, an optional alignment,
an optional :ref:`comdat <langref_comdats>`,
-an optional :ref:`garbage collector name <gc>`, an optional :ref:`prefix <prefixdata>`, an opening
+an optional :ref:`garbage collector name <gc>`, an optional :ref:`prefix <prefixdata>`,
+an optional :ref:`prologue <prologuedata>`, an opening
curly brace, a list of basic blocks, and a closing curly brace.
LLVM function declarations consist of the "``declare``" keyword, an
an optional ``unnamed_addr`` attribute, a return type, an optional
:ref:`parameter attribute <paramattrs>` for the return type, a function
name, a possibly empty list of arguments, an optional alignment, an optional
-:ref:`garbage collector name <gc>` and an optional :ref:`prefix <prefixdata>`.
+:ref:`garbage collector name <gc>`, an optional :ref:`prefix <prefixdata>`,
+and an optional :ref:`prologue <prologuedata>`.
A function definition contains a list of basic blocks, forming the CFG (Control
Flow Graph) for the function. Each basic block may optionally start with a label
LLVM allows an explicit section to be specified for functions. If the
target supports it, it will emit functions to the section specified.
-Additionally, the function can placed in a COMDAT.
+Additionally, the function can be placed in a COMDAT.
An explicit alignment may be specified for a function. If not present,
or if the alignment is set to zero, the alignment of the function is set
is specified, the function is forced to have at least that much
alignment. All alignments must be a power of 2.
-If the ``unnamed_addr`` attribute is given, the address is know to not
+If the ``unnamed_addr`` attribute is given, the address is known to not
be significant and two identical functions can be merged.
Syntax::
define [linkage] [visibility] [DLLStorageClass]
[cconv] [ret attrs]
<ResultType> @<FunctionName> ([argument list])
- [unnamed_addr] [fn Attrs] [section "name"] [comdat $<ComdatName>]
- [align N] [gc] [prefix Constant] { ... }
+ [unnamed_addr] [fn Attrs] [section "name"] [comdat [($name)]]
+ [align N] [gc] [prefix Constant] [prologue Constant] { ... }
+
+The argument list is a comma seperated sequence of arguments where each
+argument is of the following form
+
+Syntax::
+
+ <type> [parameter Attrs] [name]
+
.. _langref_aliases:
Syntax::
- @<Name> = [
Visibility] [DLLStorageClass] [ThreadLocal] [unnamed_addr] alias [Linkage] <AliaseeTy> @<Aliasee>
+ @<Name> = [
Linkage] [Visibility] [DLLStorageClass] [ThreadLocal] [unnamed_addr] alias <AliaseeTy> @<Aliasee>
The linkage must be one of ``private``, ``internal``, ``linkonce``, ``weak``,
``linkonce_odr``, ``weak_odr``, ``external``. Note that some system linkers
might not correctly handle dropping a weak symbol that is aliased.
-Alias that are not ``unnamed_addr`` are guaranteed to have the same address as
+Aliases that are not ``unnamed_addr`` are guaranteed to have the same address as
the aliasee expression. ``unnamed_addr`` ones are only guaranteed to point
to the same content.
Comdat IR provides access to COFF and ELF object file COMDAT functionality.
-Comdats have a name which represents the COMDAT key. All global objects which
+Comdats have a name which represents the COMDAT key. All global objects that
specify this key will only end up in the final object file if the linker chooses
that key over some other key. Aliases are placed in the same COMDAT that their
aliasee computes to, if any.
.. code-block:: llvm
$foo = comdat largest
- @foo = global i32 2, comdat $foo
+ @foo = global i32 2, comdat($foo)
- define void @bar() comdat $foo {
+ define void @bar() comdat($foo) {
ret void
}
+As a syntactic sugar the ``$name`` can be omitted if the name is the same as
+the global name:
+
+.. code-block:: llvm
+
+ $foo = comdat any
+ @foo = global i32 2, comdat
+
+
In a COFF object file, this will create a COMDAT section with selection kind
``IMAGE_COMDAT_SELECT_LARGEST`` containing the contents of the ``@foo`` symbol
and another COMDAT section with selection kind
``IMAGE_COMDAT_SELECT_ASSOCIATIVE`` which is associated with the first COMDAT
-section and contains the contents of the ``@baz`` symbol.
+section and contains the contents of the ``@bar`` symbol.
There are some restrictions on the properties of the global object.
It, or an alias to it, must have the same name as the COMDAT group when
$foo = comdat any
$bar = comdat any
- @g1 = global i32 42, section "sec", comdat $foo
- @g2 = global i32 42, section "sec", comdat $bar
+ @g1 = global i32 42, section "sec", comdat($foo)
+ @g2 = global i32 42, section "sec", comdat($bar)
From the object file perspective, this requires the creation of two sections
with the same name. This is necessary because both globals belong to different
Syntax::
; Some unnamed metadata nodes, which are referenced by the named metadata.
- !0 = metadata !{metadata !"zero"}
- !1 = metadata !{metadata !"one"}
- !2 = metadata !{metadata !"two"}
+ !0 = !{!"zero"}
+ !1 = !{!"one"}
+ !2 = !{!"two"}
; A named metadata.
!name = !{!0, !1, !2}
address of outgoing stack arguments. An ``inalloca`` argument must
be a pointer to stack memory produced by an ``alloca`` instruction.
The alloca, or argument allocation, must also be tagged with the
- inalloca keyword. Only the past argument may have the ``inalloca``
+ inalloca keyword. Only the last argument may have the ``inalloca``
attribute, and that argument is guaranteed to be passed in memory.
An argument allocation may be used by a call at most once because
the first parameter. This is not a valid attribute for return
values.
+``align <n>``
+ This indicates that the pointer value may be assumed by the optimizer to
+ have the specified alignment.
+
+ Note that this attribute has additional semantics when combined with the
+ ``byval`` attribute.
+
.. _noalias:
``noalias``
- This indicates that pointer values :ref:`based <pointeraliasing>` on
- the argument or return value do not alias pointer values which are
- not *based* on it, ignoring certain "irrelevant" dependencies. For a
- call to the parent function, dependencies between memory references
- from before or after the call and from those during the call are
- "irrelevant" to the ``noalias`` keyword for the arguments and return
- value used in that call. The caller shares the responsibility with
- the callee for ensuring that these requirements are met. For further
- details, please see the discussion of the NoAlias response in :ref:`alias
- analysis <Must, May, or No>`.
+ This indicates that objects accessed via pointer values
+ :ref:`based <pointeraliasing>` on the argument or return value are not also
+ accessed, during the execution of the function, via pointer values not
+ *based* on the argument or return value. The attribute on a return value
+ also has additional semantics described below. The caller shares the
+ responsibility with the callee for ensuring that these requirements are met.
+ For further details, please see the discussion of the NoAlias response in
+ :ref:`alias analysis <Must, May, or No>`.
Note that this definition of ``noalias`` is intentionally similar
- to the definition of ``restrict`` in C99 for function arguments,
- though it is slightly weaker.
+ to the definition of ``restrict`` in C99 for function arguments.
For function return values, C99's ``restrict`` is not meaningful,
- while LLVM's ``noalias`` is.
+ while LLVM's ``noalias`` is. Furthermore, the semantics of the ``noalias``
+ attribute on return values are stronger than the semantics of the attribute
+ when used on function arguments. On function return values, the ``noalias``
+ attribute indicates that the function acts like a system memory allocation
+ function, returning a pointer to allocated storage disjoint from the
+ storage for any other object accessible to the caller.
+
``nocapture``
This indicates that the callee does not make any copies of the
pointer that outlive the callee itself. This is not a valid
This indicates that the parameter or return pointer is not null. This
attribute may only be applied to pointer typed parameters. This is not
checked or enforced by LLVM, the caller must ensure that the pointer
- passed in is non-null, or the callee must ensure that the returned pointer
+ passed in is non-null, or the callee must ensure that the returned pointer
is non-null.
+``dereferenceable(<n>)``
+ This indicates that the parameter or return pointer is dereferenceable. This
+ attribute may only be applied to pointer typed parameters. A pointer that
+ is dereferenceable can be loaded from speculatively without a risk of
+ trapping. The number of bytes known to be dereferenceable must be provided
+ in parentheses. It is legal for the number of bytes to be less than the
+ size of the pointee type. The ``nonnull`` attribute does not imply
+ dereferenceability (consider a pointer to one element past the end of an
+ array), however ``dereferenceable(<n>)`` does imply ``nonnull`` in
+ ``addrspace(0)`` (which is the default address space).
+
+``dereferenceable_or_null(<n>)``
+ This indicates that the parameter or return value isn't both
+ non-null and non-dereferenceable (up to ``<n>`` bytes) at the same
+ time. All non-null pointers tagged with
+ ``dereferenceable_or_null(<n>)`` are ``dereferenceable(<n>)``.
+ For address space 0 ``dereferenceable_or_null(<n>)`` implies that
+ a pointer is exactly one of ``dereferenceable(<n>)`` or ``null``,
+ and in other address spaces ``dereferenceable_or_null(<n>)``
+ implies that a pointer is at least one of ``dereferenceable(<n>)``
+ or ``null`` (i.e. it may be both ``null`` and
+ ``dereferenceable(<n>)``). This attribute may only be applied to
+ pointer typed parameters.
+
.. _gc:
-Garbage Collector Names
------------------------
+Garbage Collector Strategy Names
+--------------------------------
-Each function may specify a garbage collector name, which is simply a
+Each function may specify a garbage collector strategy name, which is simply a
string:
.. code-block:: llvm
define void @f() gc "name" { ... }
-The compiler declares the supported values of *name*. Specifying a
-collector which will cause the compiler to alter its output in order to
-support the named garbage collection algorithm.
+The supported values of *name* includes those :ref:`built in to LLVM
+<builtin-gc-strategies>` and any provided by loaded plugins. Specifying a GC
+strategy will cause the compiler to alter its output in order to support the
+named garbage collection algorithm. Note that LLVM itself does not contain a
+garbage collector, this functionality is restricted to generating machine code
+which can interoperate with a collector provided externally.
.. _prefixdata:
Prefix Data
-----------
-Prefix data is data associated with a function which the code generator
-will emit immediately before the function body. The purpose of this feature
-is to allow frontends to associate language-specific runtime metadata with
-specific functions and make it available through the function pointer while
-still allowing the function pointer to be called. To access the data for a
-given function, a program may bitcast the function pointer to a pointer to
-the constant's type. This implies that the IR symbol points to the start
-of the prefix data.
+Prefix data is data associated with a function which the code
+generator will emit immediately before the function's entrypoint.
+The purpose of this feature is to allow frontends to associate
+language-specific runtime metadata with specific functions and make it
+available through the function pointer while still allowing the
+function pointer to be called.
+
+To access the data for a given function, a program may bitcast the
+function pointer to a pointer to the constant's type and dereference
+index -1. This implies that the IR symbol points just past the end of
+the prefix data. For instance, take the example of a function annotated
+with a single ``i32``,
+
+.. code-block:: llvm
+
+ define void @f() prefix i32 123 { ... }
+
+The prefix data can be referenced as,
+
+.. code-block:: llvm
+
+ %0 = bitcast void* () @f to i32*
+ %a = getelementptr inbounds i32, i32* %0, i32 -1
+ %b = load i32, i32* %a
-To maintain the semantics of ordinary function calls, the prefix data must
+Prefix data is laid out as if it were an initializer for a global variable
+of the prefix data's type. The function will be placed such that the
+beginning of the prefix data is aligned. This means that if the size
+of the prefix data is not a multiple of the alignment size, the
+function's entrypoint will not be aligned. If alignment of the
+function's entrypoint is desired, padding must be added to the prefix
+data.
+
+A function may have prefix data but no body. This has similar semantics
+to the ``available_externally`` linkage in that the data may be used by the
+optimizers but will not be emitted in the object file.
+
+.. _prologuedata:
+
+Prologue Data
+-------------
+
+The ``prologue`` attribute allows arbitrary code (encoded as bytes) to
+be inserted prior to the function body. This can be used for enabling
+function hot-patching and instrumentation.
+
+To maintain the semantics of ordinary function calls, the prologue data must
have a particular format. Specifically, it must begin with a sequence of
bytes which decode to a sequence of machine instructions, valid for the
module's target, which transfer control to the point immediately succeeding
-the prefix data, without performing any other visible action. This allows
+the prologue data, without performing any other visible action. This allows
the inliner and other passes to reason about the semantics of the function
-definition without needing to reason about the prefix data. Obviously this
-makes the format of the prefix data highly target dependent.
-
-Prefix data is laid out as if it were an initializer for a global variable
-of the prefix data's type. No padding is automatically placed between the
-prefix data and the function body. If padding is required, it must be part
-of the prefix data.
+definition without needing to reason about the prologue data. Obviously this
+makes the format of the prologue data highly target dependent.
-A trivial example of valid prefix data for the x86 architecture is ``i8 144``,
+A trivial example of valid prologue data for the x86 architecture is ``i8 144``,
which encodes the ``nop`` instruction:
.. code-block:: llvm
- define void @f() prefix i8 144 { ... }
+ define void @f() prologue i8 144 { ... }
-Generally prefix data can be formed by encoding a relative branch instruction
-which skips the metadata, as in this example of valid prefix data for the
+Generally prologue data can be formed by encoding a relative branch instruction
+which skips the metadata, as in this example of valid prologue data for the
x86_64 architecture, where the first two bytes encode ``jmp .+10``:
.. code-block:: llvm
%0 = type <{ i8, i8, i8* }>
- define void @f() prefix %0 <{ i8 235, i8 8, i8* @md}> { ... }
+ define void @f() prologue %0 <{ i8 235, i8 8, i8* @md}> { ... }
-A function may have prefix data but no body. This has similar semantics
+A function may have prologue data but no body. This has similar semantics
to the ``available_externally`` linkage in that the data may be used by the
optimizers but will not be emitted in the object file.
This indicates that the callee function at a call site should be
recognized as a built-in function, even though the function's declaration
uses the ``nobuiltin`` attribute. This is only valid at call sites for
- direct calls to functions which are declared with the ``nobuiltin``
+ direct calls to functions that are declared with the ``nobuiltin``
attribute.
``cold``
This attribute indicates that this function is rarely called. When
computing edge weights, basic blocks post-dominated by a cold
function call are also considered to be cold; and, thus, given low
weight.
+``convergent``
+ This attribute indicates that the callee is dependent on a convergent
+ thread execution pattern under certain parallel execution models.
+ Transformations that are execution model agnostic may only move or
+ tranform this call if the final location is control equivalent to its
+ original position in the program, where control equivalence is defined as
+ A dominates B and B post-dominates A, or vice versa.
``inlinehint``
This attribute indicates that the source code contained a hint that
inlining this function is desirable (such as the "inline" keyword in
normally. This produces undefined behavior at runtime if the
function ever does dynamically return.
``nounwind``
- This function attribute indicates that the function never returns
- with an unwind or exceptional control flow. If the function does
- unwind, its runtime behavior is undefined.
+ This function attribute indicates that the function never raises an
+ exception. If the function does raise an exception, its runtime
+ behavior is undefined. However, functions marked nounwind may still
+ trap or generate asynchronous exceptions. Exception handling schemes
+ that are recognized by LLVM to handle asynchronous exceptions, such
+ as SEH, will still provide their implementation defined semantics.
``optnone``
This function attribute indicates that the function is not optimized
by any optimization or code generator passes with the
If a function that has an ``sspstrong`` attribute is inlined into a
function that doesn't have an ``sspstrong`` attribute, then the
resulting function will have an ``sspstrong`` attribute.
+``"thunk"``
+ This attribute indicates that the function will delegate to some other
+ function with a tail call. The prototype of a thunk should not be used for
+ optimization purposes. The caller is expected to cast the thunk prototype to
+ match the thunk target prototype.
``uwtable``
This attribute indicates that the ABI being targeted requires that
an unwind table entry be produce for this function even if we can
Instead, if specified, the target data layout is required to match what
the ultimate *code generator* expects. This string is used by the
mid-level optimizers to improve code, and this only works if it matches
-what the ultimate code generator uses. If you would like to generate IR
-that does not embed this target-specific detail into the IR, then you
-don't have to specify the string. This will disable some optimizations
-that require precise layout information, but this also prevents those
-optimizations from introducing target specificity into the IR.
+what the ultimate code generator uses. There is no way to generate IR
+that does not embed this target-specific detail into the IR. If you
+don't specify the string, the default specifications will be used to
+generate a Data Layout and the optimization phases will operate
+accordingly and introduce target specificity into the IR with respect to
+these default specifications.
.. _langref_triple:
following rules:
- A pointer value formed from a ``getelementptr`` operation is *based*
- on the first operand of the ``getelementptr``.
+ on the first value operand of the ``getelementptr``.
- The result value of a ``bitcast`` is *based* on the operand of the
``bitcast``.
- A pointer value formed by an ``inttoptr`` is *based* on all pointer
- If R is volatile, the result is target-dependent. (Volatile is
supposed to give guarantees which can support ``sig_atomic_t`` in
- C/C++, and may be used for accesses to addresses which do not behave
+ C/C++, and may be used for accesses to addresses that do not behave
like normal memory. It does not generally provide cross-thread
synchronization.)
- Otherwise, if there is no write to the same byte that happens before
address. This corresponds to the C++0x/C1x ``memory_order_acq_rel``.
``seq_cst`` (sequentially consistent)
In addition to the guarantees of ``acq_rel`` (``acquire`` for an
- operation which only reads, ``release`` for an operation which only
+ operation that only reads, ``release`` for an operation that only
writes), there is a global total order on all
sequentially-consistent operations on all addresses, which is
consistent with the *happens-before* partial order and with the
LLVM IR floating-point binary ops (:ref:`fadd <i_fadd>`,
:ref:`fsub <i_fsub>`, :ref:`fmul <i_fmul>`, :ref:`fdiv <i_fdiv>`,
-:ref:`frem <i_frem>`) have the following flags that can set to enable
+:ref:`frem <i_frem>`) have the following flags that can be set to enable
otherwise unsafe floating point operations
``nnan``
dramatically change results in floating point (e.g. reassociate). This
flag implies all the others.
+.. _uselistorder:
+
+Use-list Order Directives
+-------------------------
+
+Use-list directives encode the in-memory order of each use-list, allowing the
+order to be recreated. ``<order-indexes>`` is a comma-separated list of
+indexes that are assigned to the referenced value's uses. The referenced
+value's use-list is immediately sorted by these indexes.
+
+Use-list directives may appear at function scope or global scope. They are not
+instructions, and have no effect on the semantics of the IR. When they're at
+function scope, they must appear after the terminator of the final basic block.
+
+If basic blocks have their address taken via ``blockaddress()`` expressions,
+``uselistorder_bb`` can be used to reorder their use-lists from outside their
+function's scope.
+
+:Syntax:
+
+::
+
+ uselistorder <ty> <value>, { <order-indexes> }
+ uselistorder_bb @function, %block { <order-indexes> }
+
+:Examples:
+
+::
+
+ define void @foo(i32 %arg1, i32 %arg2) {
+ entry:
+ ; ... instructions ...
+ bb:
+ ; ... instructions ...
+
+ ; At function scope.
+ uselistorder i32 %arg1, { 1, 0, 2 }
+ uselistorder label %bb, { 1, 0 }
+ }
+
+ ; At global scope.
+ uselistorder i32* @global, { 1, 2, 0 }
+ uselistorder i32 7, { 1, 0 }
+ uselistorder i32 (i32) @bar, { 1, 0 }
+ uselistorder_bb @foo, %bb, { 5, 1, 3, 2, 0, 4 }
+
.. _typesystem:
Type System
< <# elements> x <elementtype> >
The number of elements is a constant integer value larger than 0;
-elementtype may be any integer or floating point type, or a pointer to
-these types. Vectors of size zero are not allowed.
+elementtype may be any integer, floating point or pointer type. Vectors
+of size zero are not allowed.
:Examples:
square brackets (``[]``)). For example:
"``[ i32 42, i32 11, i32 74 ]``". Array constants must have
:ref:`array type <t_array>`, and the number and types of elements must
- match those specified by the type.
+ match those specified by the type. As a special case, character array
+ constants may also be represented as a double-quoted string using the ``c``
+ prefix. For example: "``c"Hello World\0A\00"``".
**Vector constants**
Vector constants are represented with notation similar to vector
type definitions (a comma separated list of elements, surrounded by
having to print large zero initializers (e.g. for large arrays) and
is always exactly equivalent to using explicit zero initializers.
**Metadata node**
- A metadata node is a structure-like constant with :ref:`metadata
- type <t_metadata>`. For example:
- "``metadata !{ i32 0, metadata !"test" }``". Unlike other
- constants that are meant to be interpreted as part of the
- instruction stream, metadata is a place to attach additional
+ A metadata node is a constant tuple without types. For example:
+ "``!{!0, !{!2, !0}, !"test"}``". Metadata can reference constant values,
+ for example: "``!{!0, i32 0, i8* @global, i64 (i64)* @function, !"str"}``".
+ Unlike other typed constants that are meant to be interpreted as part of
+ the instruction stream, metadata is a place to attach additional
information such as debug info.
Global Variable and Function Addresses
%C = xor %B, %B
%D = undef
- %E = icmp lt %D, 4
+ %E = icmp slt %D, 4
%F = icmp gte %D, 4
Safe:
Poison values are similar to :ref:`undef values <undefvalues>`, however
they also represent the fact that an instruction or constant expression
-which cannot evoke side effects has nevertheless detected a condition
-which results in undefined behavior.
+that cannot evoke side effects has nevertheless detected a condition
+that results in undefined behavior.
There is currently no way of representing a poison value in the IR; they
only exist when produced by operations such as :ref:`add <i_add>` with
successor.
- Dependence is transitive.
-Poison Values have the same behavior as :ref:`undef values <undefvalues>`,
-with the additional affect that any instruction which has a *dependence*
+Poison values have the same behavior as :ref:`undef values <undefvalues>`,
+with the additional effect that any instruction that has a *dependence*
on a poison value has undefined behavior.
Here are some examples:
entry:
%poison = sub nuw i32 0, 1 ; Results in a poison value.
%still_poison = and i32 %poison, 0 ; 0, but also poison.
- %poison_yet_again = getelementptr i32* @h, i32 %still_poison
+ %poison_yet_again = getelementptr i32, i32* @h, i32 %still_poison
store i32 0, i32* %poison_yet_again ; memory at @h[0] is poisoned
store i32 %poison, i32* @g ; Poison value stored to memory.
- %poison2 = load i32* @g ; Poison value loaded back from memory.
+ %poison2 = load i32, i32* @g ; Poison value loaded back from memory.
store volatile i32 %poison, i32* @g ; External observation; undefined behavior.
%narrowaddr = bitcast i32* @g to i16*
%wideaddr = bitcast i32* @g to i64*
- %poison3 = load i16* %narrowaddr ; Returns a poison value.
- %poison4 = load i64* %wideaddr ; Returns a poison value.
+ %poison3 = load i16, i16* %narrowaddr ; Returns a poison value.
+ %poison4 = load i64, i64* %wideaddr ; Returns a poison value.
%cmp = icmp slt i32 %poison, 0 ; Returns a poison value.
br i1 %cmp, label %true, label %end ; Branch to either destination.
Convert a constant pointer or constant vector of pointer, CST, to another
TYPE in a different address space. The constraints of the operands are the
same as those for the :ref:`addrspacecast instruction <i_addrspacecast>`.
-``getelementptr (CSTPTR, IDX0, IDX1, ...)``, ``getelementptr inbounds (CSTPTR, IDX0, IDX1, ...)``
+``getelementptr (TY, CSTPTR, IDX0, IDX1, ...)``, ``getelementptr inbounds (TY, CSTPTR, IDX0, IDX1, ...)``
Perform the :ref:`getelementptr operation <i_getelementptr>` on
constants. As with the :ref:`getelementptr <i_getelementptr>`
instruction, the index list may have zero or more indexes, which are
- required to make sense for the type of "CSTPTR".
+ required to make sense for the type of "pointer to TY".
``select (COND, VAL1, VAL2)``
Perform the :ref:`select operation <i_select>` on constants.
``icmp COND (VAL1, VAL2)``
.. _metadata:
-Metadata Nodes and Metadata Strings
------------------------------------
+Metadata
+========
LLVM IR allows metadata to be attached to instructions in the program
that can convey extra information about the code to the optimizers and
code generator. One example application of metadata is source-level
debug information. There are two metadata primitives: strings and nodes.
-All metadata has the ``metadata`` type and is identified in syntax by a
-preceding exclamation point ('``!``').
+
+Metadata does not have a type, and is not a value. If referenced from a
+``call`` instruction, it uses the ``metadata`` type.
+
+All metadata are identified in syntax by a exclamation point ('``!``').
+
+.. _metadata-string:
+
+Metadata Nodes and Metadata Strings
+-----------------------------------
A metadata string is a string surrounded by double quotes. It can
contain any character by escaping non-printable characters with
.. code-block:: llvm
- !{ metadata !"test\00", i32 10}
+ !{ !"test\00", i32 10}
+
+Metadata nodes that aren't uniqued use the ``distinct`` keyword. For example:
+
+.. code-block:: llvm
+
+ !0 = distinct !{!"test\00", i32 10}
+
+``distinct`` nodes are useful when nodes shouldn't be merged based on their
+content. They can also occur when transformations cause uniquing collisions
+when metadata operands change.
A :ref:`named metadata <namedmetadatastructure>` is a collection of
metadata nodes, which can be looked up in the module symbol table. For
.. code-block:: llvm
- !foo = metadata !{!4, !3}
+ !foo = !{!4, !3}
Metadata can be used as function arguments. Here ``llvm.dbg.value``
function is using two metadata arguments:
More information about specific metadata nodes recognized by the
optimizers and code generator is found below.
+.. _specialized-metadata:
+
+Specialized Metadata Nodes
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Specialized metadata nodes are custom data structures in metadata (as opposed
+to generic tuples). Their fields are labelled, and can be specified in any
+order.
+
+These aren't inherently debug info centric, but currently all the specialized
+metadata nodes are related to debug info.
+
+.. _DICompileUnit:
+
+DICompileUnit
+"""""""""""""
+
+``DICompileUnit`` nodes represent a compile unit. The ``enums:``,
+``retainedTypes:``, ``subprograms:``, ``globals:`` and ``imports:`` fields are
+tuples containing the debug info to be emitted along with the compile unit,
+regardless of code optimizations (some nodes are only emitted if there are
+references to them from instructions).
+
+.. code-block:: llvm
+
+ !0 = !DICompileUnit(language: DW_LANG_C99, file: !1, producer: "clang",
+ isOptimized: true, flags: "-O2", runtimeVersion: 2,
+ splitDebugFilename: "abc.debug", emissionKind: 1,
+ enums: !2, retainedTypes: !3, subprograms: !4,
+ globals: !5, imports: !6)
+
+Compile unit descriptors provide the root scope for objects declared in a
+specific compilation unit. File descriptors are defined using this scope.
+These descriptors are collected by a named metadata ``!llvm.dbg.cu``. They
+keep track of subprograms, global variables, type information, and imported
+entities (declarations and namespaces).
+
+.. _DIFile:
+
+DIFile
+""""""
+
+``DIFile`` nodes represent files. The ``filename:`` can include slashes.
+
+.. code-block:: llvm
+
+ !0 = !DIFile(filename: "path/to/file", directory: "/path/to/dir")
+
+Files are sometimes used in ``scope:`` fields, and are the only valid target
+for ``file:`` fields.
+
+.. _DIBasicType:
+
+DIBasicType
+"""""""""""
+
+``DIBasicType`` nodes represent primitive types, such as ``int``, ``bool`` and
+``float``. ``tag:`` defaults to ``DW_TAG_base_type``.
+
+.. code-block:: llvm
+
+ !0 = !DIBasicType(name: "unsigned char", size: 8, align: 8,
+ encoding: DW_ATE_unsigned_char)
+ !1 = !DIBasicType(tag: DW_TAG_unspecified_type, name: "decltype(nullptr)")
+
+The ``encoding:`` describes the details of the type. Usually it's one of the
+following:
+
+.. code-block:: llvm
+
+ DW_ATE_address = 1
+ DW_ATE_boolean = 2
+ DW_ATE_float = 4
+ DW_ATE_signed = 5
+ DW_ATE_signed_char = 6
+ DW_ATE_unsigned = 7
+ DW_ATE_unsigned_char = 8
+
+.. _DISubroutineType:
+
+DISubroutineType
+""""""""""""""""
+
+``DISubroutineType`` nodes represent subroutine types. Their ``types:`` field
+refers to a tuple; the first operand is the return type, while the rest are the
+types of the formal arguments in order. If the first operand is ``null``, that
+represents a function with no return value (such as ``void foo() {}`` in C++).
+
+.. code-block:: llvm
+
+ !0 = !BasicType(name: "int", size: 32, align: 32, DW_ATE_signed)
+ !1 = !BasicType(name: "char", size: 8, align: 8, DW_ATE_signed_char)
+ !2 = !DISubroutineType(types: !{null, !0, !1}) ; void (int, char)
+
+.. _DIDerivedType:
+
+DIDerivedType
+"""""""""""""
+
+``DIDerivedType`` nodes represent types derived from other types, such as
+qualified types.
+
+.. code-block:: llvm
+
+ !0 = !DIBasicType(name: "unsigned char", size: 8, align: 8,
+ encoding: DW_ATE_unsigned_char)
+ !1 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !0, size: 32,
+ align: 32)
+
+The following ``tag:`` values are valid:
+
+.. code-block:: llvm
+
+ DW_TAG_formal_parameter = 5
+ DW_TAG_member = 13
+ DW_TAG_pointer_type = 15
+ DW_TAG_reference_type = 16
+ DW_TAG_typedef = 22
+ DW_TAG_ptr_to_member_type = 31
+ DW_TAG_const_type = 38
+ DW_TAG_volatile_type = 53
+ DW_TAG_restrict_type = 55
+
+``DW_TAG_member`` is used to define a member of a :ref:`composite type
+<DICompositeType>` or :ref:`subprogram <DISubprogram>`. The type of the member
+is the ``baseType:``. The ``offset:`` is the member's bit offset.
+``DW_TAG_formal_parameter`` is used to define a member which is a formal
+argument of a subprogram.
+
+``DW_TAG_typedef`` is used to provide a name for the ``baseType:``.
+
+``DW_TAG_pointer_type``, ``DW_TAG_reference_type``, ``DW_TAG_const_type``,
+``DW_TAG_volatile_type`` and ``DW_TAG_restrict_type`` are used to qualify the
+``baseType:``.
+
+Note that the ``void *`` type is expressed as a type derived from NULL.
+
+.. _DICompositeType:
+
+DICompositeType
+"""""""""""""""
+
+``DICompositeType`` nodes represent types composed of other types, like
+structures and unions. ``elements:`` points to a tuple of the composed types.
+
+If the source language supports ODR, the ``identifier:`` field gives the unique
+identifier used for type merging between modules. When specified, other types
+can refer to composite types indirectly via a :ref:`metadata string
+<metadata-string>` that matches their identifier.
+
+.. code-block:: llvm
+
+ !0 = !DIEnumerator(name: "SixKind", value: 7)
+ !1 = !DIEnumerator(name: "SevenKind", value: 7)
+ !2 = !DIEnumerator(name: "NegEightKind", value: -8)
+ !3 = !DICompositeType(tag: DW_TAG_enumeration_type, name: "Enum", file: !12,
+ line: 2, size: 32, align: 32, identifier: "_M4Enum",
+ elements: !{!0, !1, !2})
+
+The following ``tag:`` values are valid:
+
+.. code-block:: llvm
+
+ DW_TAG_array_type = 1
+ DW_TAG_class_type = 2
+ DW_TAG_enumeration_type = 4
+ DW_TAG_structure_type = 19
+ DW_TAG_union_type = 23
+ DW_TAG_subroutine_type = 21
+ DW_TAG_inheritance = 28
+
+
+For ``DW_TAG_array_type``, the ``elements:`` should be :ref:`subrange
+descriptors <DISubrange>`, each representing the range of subscripts at that
+level of indexing. The ``DIFlagVector`` flag to ``flags:`` indicates that an
+array type is a native packed vector.
+
+For ``DW_TAG_enumeration_type``, the ``elements:`` should be :ref:`enumerator
+descriptors <DIEnumerator>`, each representing the definition of an enumeration
+value for the set. All enumeration type descriptors are collected in the
+``enums:`` field of the :ref:`compile unit <DICompileUnit>`.
+
+For ``DW_TAG_structure_type``, ``DW_TAG_class_type``, and
+``DW_TAG_union_type``, the ``elements:`` should be :ref:`derived types
+<DIDerivedType>` with ``tag: DW_TAG_member`` or ``tag: DW_TAG_inheritance``.
+
+.. _DISubrange:
+
+DISubrange
+""""""""""
+
+``DISubrange`` nodes are the elements for ``DW_TAG_array_type`` variants of
+:ref:`DICompositeType`. ``count: -1`` indicates an empty array.
+
+.. code-block:: llvm
+
+ !0 = !DISubrange(count: 5, lowerBound: 0) ; array counting from 0
+ !1 = !DISubrange(count: 5, lowerBound: 1) ; array counting from 1
+ !2 = !DISubrange(count: -1) ; empty array.
+
+.. _DIEnumerator:
+
+DIEnumerator
+""""""""""""
+
+``DIEnumerator`` nodes are the elements for ``DW_TAG_enumeration_type``
+variants of :ref:`DICompositeType`.
+
+.. code-block:: llvm
+
+ !0 = !DIEnumerator(name: "SixKind", value: 7)
+ !1 = !DIEnumerator(name: "SevenKind", value: 7)
+ !2 = !DIEnumerator(name: "NegEightKind", value: -8)
+
+DITemplateTypeParameter
+"""""""""""""""""""""""
+
+``DITemplateTypeParameter`` nodes represent type parameters to generic source
+language constructs. They are used (optionally) in :ref:`DICompositeType` and
+:ref:`DISubprogram` ``templateParams:`` fields.
+
+.. code-block:: llvm
+
+ !0 = !DITemplateTypeParameter(name: "Ty", type: !1)
+
+DITemplateValueParameter
+""""""""""""""""""""""""
+
+``DITemplateValueParameter`` nodes represent value parameters to generic source
+language constructs. ``tag:`` defaults to ``DW_TAG_template_value_parameter``,
+but if specified can also be set to ``DW_TAG_GNU_template_template_param`` or
+``DW_TAG_GNU_template_param_pack``. They are used (optionally) in
+:ref:`DICompositeType` and :ref:`DISubprogram` ``templateParams:`` fields.
+
+.. code-block:: llvm
+
+ !0 = !DITemplateValueParameter(name: "Ty", type: !1, value: i32 7)
+
+DINamespace
+"""""""""""
+
+``DINamespace`` nodes represent namespaces in the source language.
+
+.. code-block:: llvm
+
+ !0 = !DINamespace(name: "myawesomeproject", scope: !1, file: !2, line: 7)
+
+DIGlobalVariable
+""""""""""""""""
+
+``DIGlobalVariable`` nodes represent global variables in the source language.
+
+.. code-block:: llvm
+
+ !0 = !DIGlobalVariable(name: "foo", linkageName: "foo", scope: !1,
+ file: !2, line: 7, type: !3, isLocal: true,
+ isDefinition: false, variable: i32* @foo,
+ declaration: !4)
+
+All global variables should be referenced by the `globals:` field of a
+:ref:`compile unit <DICompileUnit>`.
+
+.. _DISubprogram:
+
+DISubprogram
+""""""""""""
+
+``DISubprogram`` nodes represent functions from the source language. The
+``variables:`` field points at :ref:`variables <DILocalVariable>` that must be
+retained, even if their IR counterparts are optimized out of the IR. The
+``type:`` field must point at an :ref:`DISubroutineType`.
+
+.. code-block:: llvm
+
+ !0 = !DISubprogram(name: "foo", linkageName: "_Zfoov", scope: !1,
+ file: !2, line: 7, type: !3, isLocal: true,
+ isDefinition: false, scopeLine: 8, containingType: !4,
+ virtuality: DW_VIRTUALITY_pure_virtual, virtualIndex: 10,
+ flags: DIFlagPrototyped, isOptimized: true,
+ function: void ()* @_Z3foov,
+ templateParams: !5, declaration: !6, variables: !7)
+
+.. _DILexicalBlock:
+
+DILexicalBlock
+""""""""""""""
+
+``DILexicalBlock`` nodes describe nested blocks within a :ref:`subprogram
+<DISubprogram>`. The line number and column numbers are used to dinstinguish
+two lexical blocks at same depth. They are valid targets for ``scope:``
+fields.
+
+.. code-block:: llvm
+
+ !0 = distinct !DILexicalBlock(scope: !1, file: !2, line: 7, column: 35)
+
+Usually lexical blocks are ``distinct`` to prevent node merging based on
+operands.
+
+.. _DILexicalBlockFile:
+
+DILexicalBlockFile
+""""""""""""""""""
+
+``DILexicalBlockFile`` nodes are used to discriminate between sections of a
+:ref:`lexical block <DILexicalBlock>`. The ``file:`` field can be changed to
+indicate textual inclusion, or the ``discriminator:`` field can be used to
+discriminate between control flow within a single block in the source language.
+
+.. code-block:: llvm
+
+ !0 = !DILexicalBlock(scope: !3, file: !4, line: 7, column: 35)
+ !1 = !DILexicalBlockFile(scope: !0, file: !4, discriminator: 0)
+ !2 = !DILexicalBlockFile(scope: !0, file: !4, discriminator: 1)
+
+.. _DILocation:
+
+DILocation
+""""""""""
+
+``DILocation`` nodes represent source debug locations. The ``scope:`` field is
+mandatory, and points at an :ref:`DILexicalBlockFile`, an
+:ref:`DILexicalBlock`, or an :ref:`DISubprogram`.
+
+.. code-block:: llvm
+
+ !0 = !DILocation(line: 2900, column: 42, scope: !1, inlinedAt: !2)
+
+.. _DILocalVariable:
+
+DILocalVariable
+"""""""""""""""
+
+``DILocalVariable`` nodes represent local variables in the source language.
+Instead of ``DW_TAG_variable``, they use LLVM-specific fake tags to
+discriminate between local variables (``DW_TAG_auto_variable``) and subprogram
+arguments (``DW_TAG_arg_variable``). In the latter case, the ``arg:`` field
+specifies the argument position, and this variable will be included in the
+``variables:`` field of its :ref:`DISubprogram`.
+
+.. code-block:: llvm
+
+ !0 = !DILocalVariable(tag: DW_TAG_arg_variable, name: "this", arg: 0,
+ scope: !3, file: !2, line: 7, type: !3,
+ flags: DIFlagArtificial)
+ !1 = !DILocalVariable(tag: DW_TAG_arg_variable, name: "x", arg: 1,
+ scope: !4, file: !2, line: 7, type: !3)
+ !1 = !DILocalVariable(tag: DW_TAG_auto_variable, name: "y",
+ scope: !5, file: !2, line: 7, type: !3)
+
+DIExpression
+""""""""""""
+
+``DIExpression`` nodes represent DWARF expression sequences. They are used in
+:ref:`debug intrinsics<dbg_intrinsics>` (such as ``llvm.dbg.declare``) to
+describe how the referenced LLVM variable relates to the source language
+variable.
+
+The current supported vocabulary is limited:
+
+- ``DW_OP_deref`` dereferences the working expression.
+- ``DW_OP_plus, 93`` adds ``93`` to the working expression.
+- ``DW_OP_bit_piece, 16, 8`` specifies the offset and size (``16`` and ``8``
+ here, respectively) of the variable piece from the working expression.
+
+.. code-block:: llvm
+
+ !0 = !DIExpression(DW_OP_deref)
+ !1 = !DIExpression(DW_OP_plus, 3)
+ !2 = !DIExpression(DW_OP_bit_piece, 3, 7)
+ !3 = !DIExpression(DW_OP_deref, DW_OP_plus, 3, DW_OP_bit_piece, 3, 7)
+
+DIObjCProperty
+""""""""""""""
+
+``DIObjCProperty`` nodes represent Objective-C property nodes.
+
+.. code-block:: llvm
+
+ !3 = !DIObjCProperty(name: "foo", file: !1, line: 7, setter: "setFoo",
+ getter: "getFoo", attributes: 7, type: !2)
+
+DIImportedEntity
+""""""""""""""""
+
+``DIImportedEntity`` nodes represent entities (such as modules) imported into a
+compile unit.
+
+.. code-block:: llvm
+
+ !2 = !DIImportedEntity(tag: DW_TAG_imported_module, name: "foo", scope: !0,
+ entity: !1, line: 7)
+
'``tbaa``' Metadata
^^^^^^^^^^^^^^^^^^^
.. code-block:: llvm
- !0 = metadata !{ metadata !"an example type tree" }
- !1 = metadata !{ metadata !"int", metadata !0 }
- !2 = metadata !{ metadata !"float", metadata !0 }
- !3 = metadata !{ metadata !"const float", metadata !2, i64 1 }
+ !0 = !{ !"an example type tree" }
+ !1 = !{ !"int", !0 }
+ !2 = !{ !"float", !0 }
+ !3 = !{ !"const float", !2, i64 1 }
The first field is an identity field. It can be any value, usually a
metadata string, which uniquely identifies the type. The most important
.. code-block:: llvm
- !4 = metadata !{ i64 0, i64 4, metadata !1, i64 8, i64 4, metadata !2 }
+ !4 = !{ i64 0, i64 4, !1, i64 8, i64 4, !2 }
This describes a struct with two fields. The first is at offset 0 bytes
with size 4 bytes, and has tbaa tag !1. The second is at offset 8 bytes
4 byte gap between the two fields. This gap represents padding which
does not carry useful data and need not be preserved.
+'``noalias``' and '``alias.scope``' Metadata
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+``noalias`` and ``alias.scope`` metadata provide the ability to specify generic
+noalias memory-access sets. This means that some collection of memory access
+instructions (loads, stores, memory-accessing calls, etc.) that carry
+``noalias`` metadata can specifically be specified not to alias with some other
+collection of memory access instructions that carry ``alias.scope`` metadata.
+Each type of metadata specifies a list of scopes where each scope has an id and
+a domain. When evaluating an aliasing query, if for some domain, the set
+of scopes with that domain in one instruction's ``alias.scope`` list is a
+subset of (or equal to) the set of scopes for that domain in another
+instruction's ``noalias`` list, then the two memory accesses are assumed not to
+alias.
+
+The metadata identifying each domain is itself a list containing one or two
+entries. The first entry is the name of the domain. Note that if the name is a
+string then it can be combined accross functions and translation units. A
+self-reference can be used to create globally unique domain names. A
+descriptive string may optionally be provided as a second list entry.
+
+The metadata identifying each scope is also itself a list containing two or
+three entries. The first entry is the name of the scope. Note that if the name
+is a string then it can be combined accross functions and translation units. A
+self-reference can be used to create globally unique scope names. A metadata
+reference to the scope's domain is the second entry. A descriptive string may
+optionally be provided as a third list entry.
+
+For example,
+
+.. code-block:: llvm
+
+ ; Two scope domains:
+ !0 = !{!0}
+ !1 = !{!1}
+
+ ; Some scopes in these domains:
+ !2 = !{!2, !0}
+ !3 = !{!3, !0}
+ !4 = !{!4, !1}
+
+ ; Some scope lists:
+ !5 = !{!4} ; A list containing only scope !4
+ !6 = !{!4, !3, !2}
+ !7 = !{!3}
+
+ ; These two instructions don't alias:
+ %0 = load float, float* %c, align 4, !alias.scope !5
+ store float %0, float* %arrayidx.i, align 4, !noalias !5
+
+ ; These two instructions also don't alias (for domain !1, the set of scopes
+ ; in the !alias.scope equals that in the !noalias list):
+ %2 = load float, float* %c, align 4, !alias.scope !5
+ store float %2, float* %arrayidx.i2, align 4, !noalias !6
+
+ ; These two instructions may alias (for domain !0, the set of scopes in
+ ; the !noalias list is not a superset of, or equal to, the scopes in the
+ ; !alias.scope list):
+ %2 = load float, float* %c, align 4, !alias.scope !6
+ store float %0, float* %arrayidx.i, align 4, !noalias !7
+
'``fpmath``' Metadata
^^^^^^^^^^^^^^^^^^^^^
.. code-block:: llvm
- !0 = metadata !{ float 2.5 } ; maximum acceptable inaccuracy is 2.5 ULPs
+ !0 = !{ float 2.5 } ; maximum acceptable inaccuracy is 2.5 ULPs
+
+.. _range-metadata:
'``range``' Metadata
^^^^^^^^^^^^^^^^^^^^
.. code-block:: llvm
- %a = load i8* %x, align 1, !range !0 ; Can only be 0 or 1
- %b = load i8* %y, align 1, !range !1 ; Can only be 255 (-1), 0 or 1
+ %a = load i8, i8* %x, align 1, !range !0 ; Can only be 0 or 1
+ %b = load i8, i8* %y, align 1, !range !1 ; Can only be 255 (-1), 0 or 1
%c = call i8 @foo(), !range !2 ; Can only be 0, 1, 3, 4 or 5
%d = invoke i8 @bar() to label %cont
unwind label %lpad, !range !3 ; Can only be -2, -1, 3, 4 or 5
...
- !0 = metadata !{ i8 0, i8 2 }
- !1 = metadata !{ i8 255, i8 2 }
- !2 = metadata !{ i8 0, i8 2, i8 3, i8 6 }
- !3 = metadata !{ i8 -2, i8 0, i8 3, i8 6 }
+ !0 = !{ i8 0, i8 2 }
+ !1 = !{ i8 255, i8 2 }
+ !2 = !{ i8 0, i8 2, i8 3, i8 6 }
+ !3 = !{ i8 -2, i8 0, i8 3, i8 6 }
'``llvm.loop``'
^^^^^^^^^^^^^^^
.. code-block:: llvm
- !0 = metadata !{ metadata !0 }
- !1 = metadata !{ metadata !1 }
+ !0 = !{!0}
+ !1 = !{!1}
-The loop identifier metadata can be used to specify additional per-loop
-metadata. Any operands after the first operand can be treated as user-defined
-metadata. For example the ``llvm.loop.vectorize.unroll`` metadata is understood
-by the loop vectorizer to indicate how many times to unroll the loop:
+The loop identifier metadata can be used to specify additional
+per-loop metadata. Any operands after the first operand can be treated
+as user-defined metadata. For example the ``llvm.loop.unroll.count``
+suggests an unroll factor to the loop unroller:
.. code-block:: llvm
br i1 %exitcond, label %._crit_edge, label %.lr.ph, !llvm.loop !0
...
- !0 = metadata !{ metadata !0, metadata !1 }
- !1 = metadata !{ metadata !"llvm.loop.vectorize.unroll", i32 2 }
+ !0 = !{!0, !1}
+ !1 = !{!"llvm.loop.unroll.count", i32 4}
+
+'``llvm.loop.vectorize``' and '``llvm.loop.interleave``'
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Metadata prefixed with ``llvm.loop.vectorize`` or ``llvm.loop.interleave`` are
+used to control per-loop vectorization and interleaving parameters such as
+vectorization width and interleave count. These metadata should be used in
+conjunction with ``llvm.loop`` loop identification metadata. The
+``llvm.loop.vectorize`` and ``llvm.loop.interleave`` metadata are only
+optimization hints and the optimizer will only interleave and vectorize loops if
+it believes it is safe to do so. The ``llvm.mem.parallel_loop_access`` metadata
+which contains information about loop-carried memory dependencies can be helpful
+in determining the safety of these transformations.
+
+'``llvm.loop.interleave.count``' Metadata
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This metadata suggests an interleave count to the loop interleaver.
+The first operand is the string ``llvm.loop.interleave.count`` and the
+second operand is an integer specifying the interleave count. For
+example:
+
+.. code-block:: llvm
+
+ !0 = !{!"llvm.loop.interleave.count", i32 4}
+
+Note that setting ``llvm.loop.interleave.count`` to 1 disables interleaving
+multiple iterations of the loop. If ``llvm.loop.interleave.count`` is set to 0
+then the interleave count will be determined automatically.
+
+'``llvm.loop.vectorize.enable``' Metadata
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This metadata selectively enables or disables vectorization for the loop. The
+first operand is the string ``llvm.loop.vectorize.enable`` and the second operand
+is a bit. If the bit operand value is 1 vectorization is enabled. A value of
+0 disables vectorization:
+
+.. code-block:: llvm
+
+ !0 = !{!"llvm.loop.vectorize.enable", i1 0}
+ !1 = !{!"llvm.loop.vectorize.enable", i1 1}
+
+'``llvm.loop.vectorize.width``' Metadata
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This metadata sets the target width of the vectorizer. The first
+operand is the string ``llvm.loop.vectorize.width`` and the second
+operand is an integer specifying the width. For example:
+
+.. code-block:: llvm
+
+ !0 = !{!"llvm.loop.vectorize.width", i32 4}
+
+Note that setting ``llvm.loop.vectorize.width`` to 1 disables
+vectorization of the loop. If ``llvm.loop.vectorize.width`` is set to
+0 or if the loop does not have this metadata the width will be
+determined automatically.
+
+'``llvm.loop.unroll``'
+^^^^^^^^^^^^^^^^^^^^^^
+
+Metadata prefixed with ``llvm.loop.unroll`` are loop unrolling
+optimization hints such as the unroll factor. ``llvm.loop.unroll``
+metadata should be used in conjunction with ``llvm.loop`` loop
+identification metadata. The ``llvm.loop.unroll`` metadata are only
+optimization hints and the unrolling will only be performed if the
+optimizer believes it is safe to do so.
+
+'``llvm.loop.unroll.count``' Metadata
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This metadata suggests an unroll factor to the loop unroller. The
+first operand is the string ``llvm.loop.unroll.count`` and the second
+operand is a positive integer specifying the unroll factor. For
+example:
+
+.. code-block:: llvm
+
+ !0 = !{!"llvm.loop.unroll.count", i32 4}
+
+If the trip count of the loop is less than the unroll count the loop
+will be partially unrolled.
+
+'``llvm.loop.unroll.disable``' Metadata
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This metadata either disables loop unrolling. The metadata has a single operand
+which is the string ``llvm.loop.unroll.disable``. For example:
+
+.. code-block:: llvm
+
+ !0 = !{!"llvm.loop.unroll.disable"}
+
+'``llvm.loop.unroll.runtime.disable``' Metadata
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This metadata either disables runtime loop unrolling. The metadata has a single
+operand which is the string ``llvm.loop.unroll.runtime.disable``. For example:
+
+.. code-block:: llvm
+
+ !0 = !{!"llvm.loop.unroll.runtime.disable"}
+
+'``llvm.loop.unroll.full``' Metadata
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This metadata either suggests that the loop should be unrolled fully. The
+metadata has a single operand which is the string ``llvm.loop.unroll.disable``.
+For example:
+
+.. code-block:: llvm
+
+ !0 = !{!"llvm.loop.unroll.full"}
'``llvm.mem``'
^^^^^^^^^^^^^^^
'``llvm.mem.parallel_loop_access``' Metadata
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-The ``llvm.mem.parallel_loop_access`` metadata refers to a loop identifier,
-or metadata containing a list of loop identifiers for nested loops.
-The metadata is attached to memory accessing instructions and denotes that
-no loop carried memory dependence exist between it and other instructions denoted
+The ``llvm.mem.parallel_loop_access`` metadata refers to a loop identifier,
+or metadata containing a list of loop identifiers for nested loops.
+The metadata is attached to memory accessing instructions and denotes that
+no loop carried memory dependence exist between it and other instructions denoted
with the same loop identifier.
-Precisely, given two instructions ``m1`` and ``m2`` that both have the
-``llvm.mem.parallel_loop_access`` metadata, with ``L1`` and ``L2`` being the
-set of loops associated with that metadata, respectively, then there is no loop
-carried dependence between ``m1`` and ``m2`` for loops in both ``L1`` and
+Precisely, given two instructions ``m1`` and ``m2`` that both have the
+``llvm.mem.parallel_loop_access`` metadata, with ``L1`` and ``L2`` being the
+set of loops associated with that metadata, respectively, then there is no loop
+carried dependence between ``m1`` and ``m2`` for loops in both ``L1`` and
``L2``.
-As a special case, if all memory accessing instructions in a loop have
-``llvm.mem.parallel_loop_access`` metadata that refers to that loop, then the
-loop has no loop carried memory dependences and is considered to be a parallel
-loop.
+As a special case, if all memory accessing instructions in a loop have
+``llvm.mem.parallel_loop_access`` metadata that refers to that loop, then the
+loop has no loop carried memory dependences and is considered to be a parallel
+loop.
-Note that if not all memory access instructions have such metadata referring to
-the loop, then the loop is considered not being trivially parallel. Additional
-memory dependence analysis is required to make that determination. As a fail
-safe mechanism, this causes loops that were originally parallel to be considered
-sequential (if optimization passes that are unaware of the parallel semantics
+Note that if not all memory access instructions have such metadata referring to
+the loop, then the loop is considered not being trivially parallel. Additional
+memory dependence analysis is required to make that determination. As a fail
+safe mechanism, this causes loops that were originally parallel to be considered
+sequential (if optimization passes that are unaware of the parallel semantics
insert new memory instructions into the loop body).
Example of a loop that is considered parallel due to its correct use of
for.body:
...
- %val0 = load i32* %arrayidx, !llvm.mem.parallel_loop_access !0
+ %val0 = load i32, i32* %arrayidx, !llvm.mem.parallel_loop_access !0
...
store i32 %val0, i32* %arrayidx1, !llvm.mem.parallel_loop_access !0
...
for.end:
...
- !0 = metadata !{ metadata !0 }
+ !0 = !{!0}
It is also possible to have nested parallel loops. In that case the
memory accesses refer to a list of loop identifier metadata nodes instead of
outer.for.body:
...
- %val1 = load i32* %arrayidx3, !llvm.mem.parallel_loop_access !2
+ %val1 = load i32, i32* %arrayidx3, !llvm.mem.parallel_loop_access !2
...
br label %inner.for.body
inner.for.body:
...
- %val0 = load i32* %arrayidx1, !llvm.mem.parallel_loop_access !0
+ %val0 = load i32, i32* %arrayidx1, !llvm.mem.parallel_loop_access !0
...
store i32 %val0, i32* %arrayidx2, !llvm.mem.parallel_loop_access !0
...
outer.for.end: ; preds = %for.body
...
- !0 = metadata !{ metadata !1, metadata !2 } ; a list of loop identifiers
- !1 = metadata !{ metadata !1 } ; an identifier for the inner loop
- !2 = metadata !{ metadata !2 } ; an identifier for the outer loop
+ !0 = !{!1, !2} ; a list of loop identifiers
+ !1 = !{!1} ; an identifier for the inner loop
+ !2 = !{!2} ; an identifier for the outer loop
-'``llvm.loop.vectorize``'
-^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Metadata prefixed with ``llvm.loop.vectorize`` is used to control per-loop
-vectorization parameters such as vectorization factor and unroll factor.
-
-``llvm.loop.vectorize`` metadata should be used in conjunction with
-``llvm.loop`` loop identification metadata.
-
-'``llvm.loop.vectorize.unroll``' Metadata
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-This metadata instructs the loop vectorizer to unroll the specified
-loop exactly ``N`` times.
-
-The first operand is the string ``llvm.loop.vectorize.unroll`` and the second
-operand is an integer specifying the unroll factor. For example:
-
-.. code-block:: llvm
-
- !0 = metadata !{ metadata !"llvm.loop.vectorize.unroll", i32 4 }
-
-Note that setting ``llvm.loop.vectorize.unroll`` to 1 disables
-unrolling of the loop.
-
-If ``llvm.loop.vectorize.unroll`` is set to 0 then the amount of
-unrolling will be determined automatically.
-
-'``llvm.loop.vectorize.width``' Metadata
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-This metadata sets the target width of the vectorizer to ``N``. Without
-this metadata, the vectorizer will choose a width automatically.
-Regardless of this metadata, the vectorizer will only vectorize loops if
-it believes it is valid to do so.
-
-The first operand is the string ``llvm.loop.vectorize.width`` and the
-second operand is an integer specifying the width. For example:
-
-.. code-block:: llvm
-
- !0 = metadata !{ metadata !"llvm.loop.vectorize.width", i32 4 }
-
-Note that setting ``llvm.loop.vectorize.width`` to 1 disables
-vectorization of the loop.
+'``llvm.bitsets``'
+^^^^^^^^^^^^^^^^^^
-If ``llvm.loop.vectorize.width`` is set to 0 then the width will be
-determined automatically.
+The ``llvm.bitsets`` global metadata is used to implement
+:doc:`bitsets <BitSets>`.
Module Flags Metadata
=====================
.. code-block:: llvm
- !0 = metadata !{ i32 1, metadata !"foo", i32 1 }
- !1 = metadata !{ i32 4, metadata !"bar", i32 37 }
- !2 = metadata !{ i32 2, metadata !"qux", i32 42 }
- !3 = metadata !{ i32 3, metadata !"qux",
- metadata !{
- metadata !"foo", i32 1
+ !0 = !{ i32 1, !"foo", i32 1 }
+ !1 = !{ i32 4, !"bar", i32 37 }
+ !2 = !{ i32 2, !"qux", i32 42 }
+ !3 = !{ i32 3, !"qux",
+ !{
+ !"foo", i32 1
}
}
!llvm.module.flags = !{ !0, !1, !2, !3 }
::
- metadata !{ metadata !"foo", i32 1 }
+ !{ !"foo", i32 1 }
The behavior is to emit an error if the ``llvm.module.flags`` does not
contain a flag with the ID ``!"foo"`` that has the value '1' after linking is
linker options, presumably to link against ``libz`` and the ``Cocoa``
framework::
- !0 = metadata !{ i32 6, metadata !"Linker Options",
- metadata !{
- metadata !{ metadata !"-lz" },
- metadata !{ metadata !"-framework", metadata !"Cocoa" } } }
+ !0 = !{ i32 6, !"Linker Options",
+ !{
+ !{ !"-lz" },
+ !{ !"-framework", !"Cocoa" } } }
!llvm.module.flags = !{ !0 }
The metadata encoding as lists of lists of options, as opposed to a collapsed
enum is the smallest type which can represent all of its values::
!llvm.module.flags = !{!0, !1}
- !0 = metadata !{i32 1, metadata !"short_wchar", i32 1}
- !1 = metadata !{i32 1, metadata !"short_enum", i32 0}
+ !0 = !{i32 1, !"short_wchar", i32 1}
+ !1 = !{i32 1, !"short_enum", i32 0}
.. _intrinsicglobalvariables:
The value produced is ``op1`` \* 2\ :sup:`op2` mod 2\ :sup:`n`,
where ``n`` is the width of the result. If ``op2`` is (statically or
-dynamically) negative or equal to or larger than the number of bits in
+dynamically) equal to or larger than the number of bits in
``op1``, the result is undefined. If the arguments are vectors, each
vector element of ``op1`` is shifted by the corresponding shift amount
in ``op2``.
%agg1 = insertvalue {i32, float} undef, i32 1, 0 ; yields {i32 1, float undef}
%agg2 = insertvalue {i32, float} %agg1, float %val, 1 ; yields {i32 1, float %val}
- %agg3 = insertvalue {i32, {float}} %agg1, float %val, 1, 0 ; yields {i32 1, float %val}
+ %agg3 = insertvalue {i32, {float}} undef, float %val, 1, 0 ; yields {i32 undef, {float %val}}
.. _memoryops:
appropriate type to the program. If "NumElements" is specified, it is
the number of elements allocated, otherwise "NumElements" is defaulted
to be one. If a constant alignment is specified, the value result of the
-allocation is guaranteed to be aligned to at least that boundary. If not
-specified, or if zero, the target can choose to align the allocation on
-any convenient boundary compatible with the type.
+allocation is guaranteed to be aligned to at least that boundary. The
+alignment may not be greater than ``1 << 29``. If not specified, or if
+zero, the target can choose to align the allocation on any convenient
+boundary compatible with the type.
'``type``' may be any sized type.
::
- <result> = load [volatile] <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>][, !invariant.load !<index>]
+ <result> = load [volatile] <ty>, <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>][, !invariant.load !<index>][, !nonnull !<index>][, !dereferenceable !<index>][, !dereferenceable_or_null !<index>]
<result> = load atomic [volatile] <ty>* <pointer> [singlethread] <ordering>, align <alignment>
!<index> = !{ i32 1 }
""""""""""
The argument to the ``load`` instruction specifies the memory address
-from which to load. The pointer must point to a :ref:`first
+from which to load. The type specified must be a :ref:`first
class <t_firstclass>` type. If the ``load`` is marked as ``volatile``,
then the optimizer is not allowed to modify the number or order of
execution of this ``load`` with other :ref:`volatile
alignment for the target. It is the responsibility of the code emitter
to ensure that the alignment information is correct. Overestimating the
alignment results in undefined behavior. Underestimating the alignment
-may produce less efficient code. An alignment of 1 is always safe.
+may produce less efficient code. An alignment of 1 is always safe. The
+maximum possible alignment is ``1 << 29``.
The optional ``!nontemporal`` metadata must reference a single
metadata name ``<index>`` corresponding to a metadata node with one
The optional ``!invariant.load`` metadata must reference a single
metadata name ``<index>`` corresponding to a metadata node with no
entries. The existence of the ``!invariant.load`` metadata on the
-instruction tells the optimizer and code generator that this load
-address points to memory which does not change value during program
-execution. The optimizer may then move this load around, for example, by
-hoisting it out of loops using loop invariant code motion.
+instruction tells the optimizer and code generator that the address
+operand to this load points to memory which can be assumed unchanged.
+Being invariant does not imply that a location is dereferenceable,
+but it does imply that once the location is known dereferenceable
+its value is henceforth unchanging.
+
+The optional ``!nonnull`` metadata must reference a single
+metadata name ``<index>`` corresponding to a metadata node with no
+entries. The existence of the ``!nonnull`` metadata on the
+instruction tells the optimizer that the value loaded is known to
+never be null. This is analogous to the ''nonnull'' attribute
+on parameters and return values. This metadata can only be applied
+to loads of a pointer type.
+
+The optional ``!dereferenceable`` metadata must reference a single
+metadata name ``<index>`` corresponding to a metadata node with one ``i64``
+entry. The existence of the ``!dereferenceable`` metadata on the instruction
+tells the optimizer that the value loaded is known to be dereferenceable.
+The number of bytes known to be dereferenceable is specified by the integer
+value in the metadata node. This is analogous to the ''dereferenceable''
+attribute on parameters and return values. This metadata can only be applied
+to loads of a pointer type.
+
+The optional ``!dereferenceable_or_null`` metadata must reference a single
+metadata name ``<index>`` corresponding to a metadata node with one ``i64``
+entry. The existence of the ``!dereferenceable_or_null`` metadata on the
+instruction tells the optimizer that the value loaded is known to be either
+dereferenceable or null.
+The number of bytes known to be dereferenceable is specified by the integer
+value in the metadata node. This is analogous to the ''dereferenceable_or_null''
+attribute on parameters and return values. This metadata can only be applied
+to loads of a pointer type.
Semantics:
""""""""""
%ptr = alloca i32 ; yields i32*:ptr
store i32 3, i32* %ptr ; yields void
- %val = load i32* %ptr ; yields i32:val = i32 3
+ %val = load i32, i32* %ptr ; yields i32:val = i32 3
.. _i_store:
to ensure that the alignment information is correct. Overestimating the
alignment results in undefined behavior. Underestimating the
alignment may produce less efficient code. An alignment of 1 is always
-safe.
+safe. The maximum possible alignment is ``1 << 29``.
The optional ``!nontemporal`` metadata must reference a single metadata
name ``<index>`` corresponding to a metadata node with one ``i32`` entry of
.. code-block:: llvm
entry:
- %orig = atomic load i32* %ptr unordered ; yields i32
+ %orig = atomic load i32, i32* %ptr unordered ; yields i32
br label %loop
loop:
::
- <result> = getelementptr <
pty>* <ptrval>{, <ty> <idx>}*
- <result> = getelementptr inbounds <
pty>* <ptrval>{, <ty> <idx>}*
- <result> = getelementptr <ptr vector> ptrval, <vector index type> idx
+ <result> = getelementptr <
ty>, <ty>* <ptrval>{, <ty> <idx>}*
+ <result> = getelementptr inbounds <
ty>, <ty>* <ptrval>{, <ty> <idx>}*
+ <result> = getelementptr <ty>, <ptr vector> <ptrval>, <vector index type> <idx>
Overview:
"""""""""
Arguments:
""""""""""
-The first argument is always a pointer or a vector of pointers, and
-forms the basis of the calculation. The remaining arguments are indices
+The first argument is always a type used as the basis for the calculations.
+The second argument is always a pointer or a vector of pointers, and is the
+base address to start from. The remaining arguments are indices
that indicate which of the elements of the aggregate object are indexed.
The interpretation of each index is dependent on the type being indexed
into. The first index always indexes the pointer value given as the
define i32* @foo(%struct.ST* %s) nounwind uwtable readnone optsize ssp {
entry:
- %arrayidx = getelementptr inbounds %struct.ST* %s, i64 1, i32 2, i32 1, i64 5, i64 13
+ %arrayidx = getelementptr inbounds %struct.ST, %struct.ST* %s, i64 1, i32 2, i32 1, i64 5, i64 13
ret i32* %arrayidx
}
.. code-block:: llvm
define i32* @foo(%struct.ST* %s) {
- %t1 = getelementptr %struct.ST* %s, i32 1 ; yields %struct.ST*:%t1
- %t2 = getelementptr %struct.ST* %t1, i32 0, i32 2 ; yields %struct.RT*:%t2
- %t3 = getelementptr %struct.RT* %t2, i32 0, i32 1 ; yields [10 x [20 x i32]]*:%t3
- %t4 = getelementptr [10 x [20 x i32]]* %t3, i32 0, i32 5 ; yields [20 x i32]*:%t4
- %t5 = getelementptr [20 x i32]* %t4, i32 0, i32 13 ; yields i32*:%t5
+ %t1 = getelementptr %struct.ST, %struct.ST* %s, i32 1 ; yields %struct.ST*:%t1
+ %t2 = getelementptr %struct.ST, %struct.ST* %t1, i32 0, i32 2 ; yields %struct.RT*:%t2
+ %t3 = getelementptr %struct.RT, %struct.RT* %t2, i32 0, i32 1 ; yields [10 x [20 x i32]]*:%t3
+ %t4 = getelementptr [10 x [20 x i32]], [10 x [20 x i32]]* %t3, i32 0, i32 5 ; yields [20 x i32]*:%t4
+ %t5 = getelementptr [20 x i32], [20 x i32]* %t4, i32 0, i32 13 ; yields i32*:%t5
ret i32* %t5
}
.. code-block:: llvm
; yields [12 x i8]*:aptr
- %aptr = getelementptr {i32, [12 x i8]}* %saptr, i64 0, i32 1
+ %aptr = getelementptr {i32, [12 x i8]}, {i32, [12 x i8]}* %saptr, i64 0, i32 1
; yields i8*:vptr
- %vptr = getelementptr {i32, <2 x i8>}* %svptr, i64 0, i32 1, i32 1
+ %vptr = getelementptr {i32, <2 x i8>}, {i32, <2 x i8>}* %svptr, i64 0, i32 1, i32 1
; yields i8*:eptr
- %eptr = getelementptr [12 x i8]* %aptr, i64 0, i32 1
+ %eptr = getelementptr [12 x i8], [12 x i8]* %aptr, i64 0, i32 1
; yields i32*:iptr
- %iptr = getelementptr [10 x i32]* @arr, i16 0, i16 0
+ %iptr = getelementptr [10 x i32], [10 x i32]* @arr, i16 0, i16 0
In cases where the pointer argument is a vector of pointers, each index
must be a vector with the same number of elements. For example:
.. code-block:: llvm
- %A = getelementptr <4 x i8*> %ptrs, <4 x i64> %offsets,
+ %A = getelementptr i8, <4 x i8*> %ptrs, <4 x i64> %offsets,
Conversion Operations
---------------------
""""""""""
The '``ptrtoint``' instruction takes a ``value`` to cast, which must be
-a a value of type :ref:`pointer <t_pointer>` or a vector of pointers, and a
+a value of type :ref:`pointer <t_pointer>` or a vector of pointers, and a
type to cast it to ``ty2``, which must be an :ref:`integer <t_integer>` or
a vector of integers type.
The '``select``' instruction requires an 'i1' value or a vector of 'i1'
values indicating the condition, and two values of the same :ref:`first
-class <t_firstclass>` type. If the val1/val2 are vectors and the
-condition is a scalar, then entire vectors are selected, not individual
-elements.
+class <t_firstclass>` type.
Semantics:
""""""""""
If the condition is a vector of i1, then the value arguments must be
vectors of the same size, and the selection is done element by element.
+If the condition is an i1 and the value arguments are vectors of the
+same size, then an entire vector is selected.
+
Example:
""""""""
- The calling conventions of the caller and callee must match.
- All ABI-impacting function attributes, such as sret, byval, inreg,
returned, and inalloca, must match.
+ - The callee must be varargs iff the caller is varargs. Bitcasting a
+ non-varargs function to the appropriate varargs type is legal so
+ long as the non-varargs prefixes obey the other rules.
Tail call optimization for calls marked ``tail`` is guaranteed to occur if
the following conditions are met:
.. code-block:: llvm
+ ; This struct is different for every platform. For most platforms,
+ ; it is merely an i8*.
+ %struct.va_list = type { i8* }
+
+ ; For Unix x86_64 platforms, va_list is the following struct:
+ ; %struct.va_list = type { i32, i32, i8*, i8* }
+
define i32 @test(i32 %X, ...) {
; Initialize variable argument processing
- %ap = alloca i8*
- %ap2 = bitcast i8** %ap to i8*
+ %ap = alloca %struct.va_list
+ %ap2 = bitcast %struct.va_list* %ap to i8*
call void @llvm.va_start(i8* %ap2)
; Read a single integer argument
- %tmp = va_arg i8** %ap, i32
+ %tmp = va_arg i8* %ap2, i32
; Demonstrate usage of llvm.va_copy and llvm.va_end
%aq = alloca i8*
Accurate Garbage Collection Intrinsics
--------------------------------------
-LLVM support for `Accurate Garbage Collection <GarbageCollection.html>`_
-(GC) requires the implementation and generation of these intrinsics.
+LLVM's support for `Accurate Garbage Collection <GarbageCollection.html>`_
+(GC) requires the frontend to generate code containing appropriate intrinsic
+calls and select an appropriate GC strategy which knows how to lower these
+intrinsics in a manner which is appropriate for the target collector.
+
These intrinsics allow identification of :ref:`GC roots on the
stack <int_gcroot>`, as well as garbage collector implementations that
require :ref:`read <int_gcread>` and :ref:`write <int_gcwrite>` barriers.
-Front-ends for type-safe garbage collected languages should generate
+Frontends for type-safe garbage collected languages should generate
these intrinsics to make use of the LLVM garbage collectors. For more
-details, see `Accurate Garbage Collection with
-LLVM <GarbageCollection.html>`_.
+details, see `Garbage Collection with LLVM <GarbageCollection.html>`_.
-The garbage collection intrinsics only operate on objects in the generic
-address space (address space zero).
+Experimental Statepoint Intrinsics
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+LLVM provides an second experimental set of intrinsics for describing garbage
+collection safepoints in compiled code. These intrinsics are an alternative
+to the ``llvm.gcroot`` intrinsics, but are compatible with the ones for
+:ref:`read <int_gcread>` and :ref:`write <int_gcwrite>` barriers. The
+differences in approach are covered in the `Garbage Collection with LLVM
+<GarbageCollection.html>`_ documentation. The intrinsics themselves are
+described in :doc:`Statepoints`.
.. _int_gcroot:
::
- declare i8* @llvm.frameaddress(i32 <level>)
+ declare i8* @llvm.frameaddress(i32 <level>)
+
+Overview:
+"""""""""
+
+The '``llvm.frameaddress``' intrinsic attempts to return the
+target-specific frame pointer value for the specified stack frame.
+
+Arguments:
+""""""""""
+
+The argument to this intrinsic indicates which function to return the
+frame pointer for. Zero indicates the calling function, one indicates
+its caller, etc. The argument is **required** to be a constant integer
+value.
+
+Semantics:
+""""""""""
+
+The '``llvm.frameaddress``' intrinsic either returns a pointer
+indicating the frame address of the specified call frame, or zero if it
+cannot be identified. The value returned by this intrinsic is likely to
+be incorrect or 0 for arguments other than zero, so it should only be
+used for debugging purposes.
+
+Note that calling this intrinsic does not prevent function inlining or
+other aggressive transformations, so the value returned may not be that
+of the obvious source-language caller.
+
+'``llvm.frameescape``' and '``llvm.framerecover``' Intrinsics
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Syntax:
+"""""""
+
+::
+
+ declare void @llvm.frameescape(...)
+ declare i8* @llvm.framerecover(i8* %func, i8* %fp, i32 %idx)
Overview:
"""""""""
-The '``llvm.frameaddress``' intrinsic attempts to return the
-target-specific frame pointer value for the specified stack frame.
+The '``llvm.frameescape``' intrinsic escapes offsets of a collection of static
+allocas, and the '``llvm.framerecover``' intrinsic applies those offsets to a
+live frame pointer to recover the address of the allocation. The offset is
+computed during frame layout of the caller of ``llvm.frameescape``.
Arguments:
""""""""""
-The argument to this intrinsic indicates which function to return the
-frame pointer for. Zero indicates the calling function, one indicates
-its caller, etc. The argument is **required** to be a constant integer
-value.
+All arguments to '``llvm.frameescape``' must be pointers to static allocas or
+casts of static allocas. Each function can only call '``llvm.frameescape``'
+once, and it can only do so from the entry block.
+
+The ``func`` argument to '``llvm.framerecover``' must be a constant
+bitcasted pointer to a function defined in the current module. The code
+generator cannot determine the frame allocation offset of functions defined in
+other modules.
+
+The ``fp`` argument to '``llvm.framerecover``' must be a frame
+pointer of a call frame that is currently live. The return value of
+'``llvm.frameaddress``' is one way to produce such a value, but most platforms
+also expose the frame pointer through stack unwinding mechanisms.
+
+The ``idx`` argument to '``llvm.framerecover``' indicates which alloca passed to
+'``llvm.frameescape``' to recover. It is zero-indexed.
Semantics:
""""""""""
-The '``llvm.frameaddress``' intrinsic either returns a pointer
-indicating the frame address of the specified call frame, or zero if it
-cannot be identified. The value returned by this intrinsic is likely to
-be incorrect or 0 for arguments other than zero, so it should only be
-used for debugging purposes.
-
-Note that calling this intrinsic does not prevent function inlining or
-other aggressive transformations, so the value returned may not be that
-of the obvious source-language caller.
+These intrinsics allow a group of functions to access one stack memory
+allocation in an ancestor stack frame. The memory returned from
+'``llvm.frameallocate``' may be allocated prior to stack realignment, so the
+memory is only aligned to the ABI-required stack alignment. Each function may
+only call '``llvm.frameallocate``' one or zero times from the function entry
+block. The frame allocation intrinsic inhibits inlining, as any frame
+allocations in the inlined function frame are likely to be at a different
+offset from the one used by '``llvm.framerecover``' called with the
+uninlined function.
.. _int_read_register:
.. _int_write_register:
declare i64 @llvm.read_register.i64(metadata)
declare void @llvm.write_register.i32(metadata, i32 @value)
declare void @llvm.write_register.i64(metadata, i64 @value)
- !0 = metadata !{metadata !"sp\00"}
+ !0 = !{!"sp\00"}
Overview:
"""""""""
This instrinsic does *not* empty the instruction pipeline. Modifications
of the current function are outside the scope of the intrinsic.
+'``llvm.instrprof_increment``' Intrinsic
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Syntax:
+"""""""
+
+::
+
+ declare void @llvm.instrprof_increment(i8* <name>, i64 <hash>,
+ i32 <num-counters>, i32 <index>)
+
+Overview:
+"""""""""
+
+The '``llvm.instrprof_increment``' intrinsic can be emitted by a
+frontend for use with instrumentation based profiling. These will be
+lowered by the ``-instrprof`` pass to generate execution counts of a
+program at runtime.
+
+Arguments:
+""""""""""
+
+The first argument is a pointer to a global variable containing the
+name of the entity being instrumented. This should generally be the
+(mangled) function name for a set of counters.
+
+The second argument is a hash value that can be used by the consumer
+of the profile data to detect changes to the instrumented source, and
+the third is the number of counters associated with ``name``. It is an
+error if ``hash`` or ``num-counters`` differ between two instances of
+``instrprof_increment`` that refer to the same name.
+
+The last argument refers to which of the counters for ``name`` should
+be incremented. It should be a value between 0 and ``num-counters``.
+
+Semantics:
+""""""""""
+
+This intrinsic represents an increment of a profiling counter. It will
+cause the ``-instrprof`` pass to generate the appropriate data
+structures and the code to increment the appropriate value, in a
+format that can be written out by a compiler runtime and consumed via
+the ``llvm-profdata`` tool.
+
Standard C Library Intrinsics
-----------------------------
declare float @llvm.fabs.f32(float %Val)
declare double @llvm.fabs.f64(double %Val)
- declare x86_fp80 @llvm.fabs.f80(x86_fp80 %Val)
+ declare x86_fp80 @llvm.fabs.f80(x86_fp80 %Val)
declare fp128 @llvm.fabs.f128(fp128 %Val)
- declare ppc_fp128 @llvm.fabs.ppcf128(ppc_fp128 %Val)
+ declare ppc_fp128 @llvm.fabs.ppcf128(ppc_fp128 %Val)
Overview:
"""""""""
This function returns the same values as the libm ``fabs`` functions
would, and handles error conditions in the same way.
+'``llvm.minnum.*``' Intrinsic
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Syntax:
+"""""""
+
+This is an overloaded intrinsic. You can use ``llvm.minnum`` on any
+floating point or vector of floating point type. Not all targets support
+all types however.
+
+::
+
+ declare float @llvm.minnum.f32(float %Val0, float %Val1)
+ declare double @llvm.minnum.f64(double %Val0, double %Val1)
+ declare x86_fp80 @llvm.minnum.f80(x86_fp80 %Val0, x86_fp80 %Val1)
+ declare fp128 @llvm.minnum.f128(fp128 %Val0, fp128 %Val1)
+ declare ppc_fp128 @llvm.minnum.ppcf128(ppc_fp128 %Val0, ppc_fp128 %Val1)
+
+Overview:
+"""""""""
+
+The '``llvm.minnum.*``' intrinsics return the minimum of the two
+arguments.
+
+
+Arguments:
+""""""""""
+
+The arguments and return value are floating point numbers of the same
+type.
+
+Semantics:
+""""""""""
+
+Follows the IEEE-754 semantics for minNum, which also match for libm's
+fmin.
+
+If either operand is a NaN, returns the other non-NaN operand. Returns
+NaN only if both operands are NaN. If the operands compare equal,
+returns a value that compares equal to both operands. This means that
+fmin(+/-0.0, +/-0.0) could return either -0.0 or 0.0.
+
+'``llvm.maxnum.*``' Intrinsic
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Syntax:
+"""""""
+
+This is an overloaded intrinsic. You can use ``llvm.maxnum`` on any
+floating point or vector of floating point type. Not all targets support
+all types however.
+
+::
+
+ declare float @llvm.maxnum.f32(float %Val0, float %Val1l)
+ declare double @llvm.maxnum.f64(double %Val0, double %Val1)
+ declare x86_fp80 @llvm.maxnum.f80(x86_fp80 %Val0, x86_fp80 %Val1)
+ declare fp128 @llvm.maxnum.f128(fp128 %Val0, fp128 %Val1)
+ declare ppc_fp128 @llvm.maxnum.ppcf128(ppc_fp128 %Val0, ppc_fp128 %Val1)
+
+Overview:
+"""""""""
+
+The '``llvm.maxnum.*``' intrinsics return the maximum of the two
+arguments.
+
+
+Arguments:
+""""""""""
+
+The arguments and return value are floating point numbers of the same
+type.
+
+Semantics:
+""""""""""
+Follows the IEEE-754 semantics for maxNum, which also match for libm's
+fmax.
+
+If either operand is a NaN, returns the other non-NaN operand. Returns
+NaN only if both operands are NaN. If the operands compare equal,
+returns a value that compares equal to both operands. This means that
+fmax(+/-0.0, +/-0.0) could return either -0.0 or 0.0.
+
'``llvm.copysign.*``' Intrinsic
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
""""""""""
The first argument is the value to be counted. This argument may be of
-any integer type, or a vectory with integer element type. The return
+any integer type, or a vector with integer element type. The return
type must match the first argument type.
The second argument must be a constant and is a flag to indicate whether
""""""""""
The first argument is the value to be counted. This argument may be of
-any integer type, or a vectory with integer element type. The return
+any integer type, or a vector with integer element type. The return
type must match the first argument type.
The second argument must be a constant and is a flag to indicate whether
``is_zero_undef == 0`` and ``undef`` otherwise. For example,
``llvm.cttz(2) = 1``.
+.. _int_overflow:
+
Arithmetic with Overflow Intrinsics
-----------------------------------
::
- declare i16 @llvm.convert.to.fp16(f32 %a)
+ declare i16 @llvm.convert.to.fp16.f32(float %a)
+ declare i16 @llvm.convert.to.fp16.f64(double %a)
Overview:
"""""""""
-The '``llvm.convert.to.fp16``' intrinsic function performs a conversion
-from single precision floating point format to half precision floating
-point format.
+The '``llvm.convert.to.fp16``' intrinsic function performs a conversion from a
+conventional floating point type to half precision floating point format.
Arguments:
""""""""""
Semantics:
""""""""""
-The '``llvm.convert.to.fp16``' intrinsic function performs a conversion
-from single precision floating point format to half precision floating
-point format. The return value is an ``i16`` which contains the
-converted number.
+The '``llvm.convert.to.fp16``' intrinsic function performs a conversion from a
+conventional floating point format to half precision floating point format. The
+return value is an ``i16`` which contains the converted number.
Examples:
"""""""""
.. code-block:: llvm
- %res = call i16 @llvm.convert.to.fp16(f32 %a)
+ %res = call i16 @llvm.convert.to.fp16.f32(float %a)
store i16 %res, i16* @x, align 2
.. _int_convert_from_fp16:
::
- declare f32 @llvm.convert.from.fp16(i16 %a)
+ declare float @llvm.convert.from.fp16.f32(i16 %a)
+ declare double @llvm.convert.from.fp16.f64(i16 %a)
Overview:
"""""""""
.. code-block:: llvm
- %a = load i16* @x, align 2
- %res = call f32 @llvm.convert.from.fp16(i16 %a)
+ %a = load i16, i16* @x, align 2
+ %res = call float @llvm.convert.from.fp16(i16 %a)
+
+.. _dbg_intrinsics:
Debugger Intrinsics
-------------------
.. code-block:: llvm
%tramp = alloca [10 x i8], align 4 ; size and alignment only correct for X86
- %tramp1 = getelementptr [10 x i8]* %tramp, i32 0, i32 0
+ %tramp1 = getelementptr [10 x i8], [10 x i8]* %tramp, i32 0, i32 0
call i8* @llvm.init.trampoline(i8* %tramp1, i8* bitcast (i32 (i8*, i32, i32)* @f to i8*), i8* %nval)
%p = call i8* @llvm.adjust.trampoline(i8* %tramp1)
%fp = bitcast i8* %p to i32 (i32, i32)*
""""""""""
On some architectures the address of the code to be executed needs to be
-different to the address where the trampoline is actually stored. This
+different than the address where the trampoline is actually stored. This
intrinsic returns the executable address corresponding to ``tramp``
after performing the required machine specific adjustments. The pointer
returned can then be :ref:`bitcast and executed <int_trampoline>`.
+.. _int_mload_mstore:
+
+Masked Vector Load and Store Intrinsics
+---------------------------------------
+
+LLVM provides intrinsics for predicated vector load and store operations. The predicate is specified by a mask operand, which holds one bit per vector element, switching the associated vector lane on or off. The memory addresses corresponding to the "off" lanes are not accessed. When all bits of the mask are on, the intrinsic is identical to a regular vector load or store. When all bits are off, no memory is accessed.
+
+.. _int_mload:
+
+'``llvm.masked.load.*``' Intrinsics
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Syntax:
+"""""""
+This is an overloaded intrinsic. The loaded data is a vector of any integer or floating point data type.
+
+::
+
+ declare <16 x float> @llvm.masked.load.v16f32 (<16 x float>* <ptr>, i32 <alignment>, <16 x i1> <mask>, <16 x float> <passthru>)
+ declare <2 x double> @llvm.masked.load.v2f64 (<2 x double>* <ptr>, i32 <alignment>, <2 x i1> <mask>, <2 x double> <passthru>)
+
+Overview:
+"""""""""
+
+Reads a vector from memory according to the provided mask. The mask holds a bit for each vector lane, and is used to prevent memory accesses to the masked-off lanes. The masked-off lanes in the result vector are taken from the corresponding lanes of the '``passthru``' operand.
+
+
+Arguments:
+""""""""""
+
+The first operand is the base pointer for the load. The second operand is the alignment of the source location. It must be a constant integer value. The third operand, mask, is a vector of boolean values with the same number of elements as the return type. The fourth is a pass-through value that is used to fill the masked-off lanes of the result. The return type, underlying type of the base pointer and the type of the '``passthru``' operand are the same vector types.
+
+
+Semantics:
+""""""""""
+
+The '``llvm.masked.load``' intrinsic is designed for conditional reading of selected vector elements in a single IR operation. It is useful for targets that support vector masked loads and allows vectorizing predicated basic blocks on these targets. Other targets may support this intrinsic differently, for example by lowering it into a sequence of branches that guard scalar load operations.
+The result of this operation is equivalent to a regular vector load instruction followed by a 'select' between the loaded and the passthru values, predicated on the same mask. However, using this intrinsic prevents exceptions on memory access to masked-off lanes.
+
+
+::
+
+ %res = call <16 x float> @llvm.masked.load.v16f32 (<16 x float>* %ptr, i32 4, <16 x i1>%mask, <16 x float> %passthru)
+
+ ;; The result of the two following instructions is identical aside from potential memory access exception
+ %loadlal = load <16 x float>, <16 x float>* %ptr, align 4
+ %res = select <16 x i1> %mask, <16 x float> %loadlal, <16 x float> %passthru
+
+.. _int_mstore:
+
+'``llvm.masked.store.*``' Intrinsics
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Syntax:
+"""""""
+This is an overloaded intrinsic. The data stored in memory is a vector of any integer or floating point data type.
+
+::
+
+ declare void @llvm.masked.store.v8i32 (<8 x i32> <value>, <8 x i32> * <ptr>, i32 <alignment>, <8 x i1> <mask>)
+ declare void @llvm.masked.store.v16f32(<16 x i32> <value>, <16 x i32>* <ptr>, i32 <alignment>, <16 x i1> <mask>)
+
+Overview:
+"""""""""
+
+Writes a vector to memory according to the provided mask. The mask holds a bit for each vector lane, and is used to prevent memory accesses to the masked-off lanes.
+
+Arguments:
+""""""""""
+
+The first operand is the vector value to be written to memory. The second operand is the base pointer for the store, it has the same underlying type as the value operand. The third operand is the alignment of the destination location. The fourth operand, mask, is a vector of boolean values. The types of the mask and the value operand must have the same number of vector elements.
+
+
+Semantics:
+""""""""""
+
+The '``llvm.masked.store``' intrinsics is designed for conditional writing of selected vector elements in a single IR operation. It is useful for targets that support vector masked store and allows vectorizing predicated basic blocks on these targets. Other targets may support this intrinsic differently, for example by lowering it into a sequence of branches that guard scalar store operations.
+The result of this operation is equivalent to a load-modify-store sequence. However, using this intrinsic prevents exceptions and data races on memory access to masked-off lanes.
+
+::
+
+ call void @llvm.masked.store.v16f32(<16 x float> %value, <16 x float>* %ptr, i32 4, <16 x i1> %mask)
+
+ ;; The result of the following instructions is identical aside from potential data races and memory access exceptions
+ %oldval = load <16 x float>, <16 x float>* %ptr, align 4
+ %res = select <16 x i1> %mask, <16 x float> %value, <16 x float> %oldval
+ store <16 x float> %res, <16 x float>* %ptr, align 4
+
+
+Masked Vector Gather and Scatter Intrinsics
+-------------------------------------------
+
+LLVM provides intrinsics for vector gather and scatter operations. They are similar to :ref:`Masked Vector Load and Store <int_mload_mstore>`, except they are designed for arbitrary memory accesses, rather than sequential memory accesses. Gather and scatter also employ a mask operand, which holds one bit per vector element, switching the associated vector lane on or off. The memory addresses corresponding to the "off" lanes are not accessed. When all bits are off, no memory is accessed.
+
+.. _int_mgather:
+
+'``llvm.masked.gather.*``' Intrinsics
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Syntax:
+"""""""
+This is an overloaded intrinsic. The loaded data are multiple scalar values of any integer or floating point data type gathered together into one vector.
+
+::
+
+ declare <16 x float> @llvm.masked.gather.v16f32 (<16 x float*> <ptrs>, i32 <alignment>, <16 x i1> <mask>, <16 x float> <passthru>)
+ declare <2 x double> @llvm.masked.gather.v2f64 (<2 x double*> <ptrs>, i32 <alignment>, <2 x i1> <mask>, <2 x double> <passthru>)
+
+Overview:
+"""""""""
+
+Reads scalar values from arbitrary memory locations and gathers them into one vector. The memory locations are provided in the vector of pointers '``ptrs``'. The memory is accessed according to the provided mask. The mask holds a bit for each vector lane, and is used to prevent memory accesses to the masked-off lanes. The masked-off lanes in the result vector are taken from the corresponding lanes of the '``passthru``' operand.
+
+
+Arguments:
+""""""""""
+
+The first operand is a vector of pointers which holds all memory addresses to read. The second operand is an alignment of the source addresses. It must be a constant integer value. The third operand, mask, is a vector of boolean values with the same number of elements as the return type. The fourth is a pass-through value that is used to fill the masked-off lanes of the result. The return type, underlying type of the vector of pointers and the type of the '``passthru``' operand are the same vector types.
+
+
+Semantics:
+""""""""""
+
+The '``llvm.masked.gather``' intrinsic is designed for conditional reading of multiple scalar values from arbitrary memory locations in a single IR operation. It is useful for targets that support vector masked gathers and allows vectorizing basic blocks with data and control divergence. Other targets may support this intrinsic differently, for example by lowering it into a sequence of scalar load operations.
+The semantics of this operation are equivalent to a sequence of conditional scalar loads with subsequent gathering all loaded values into a single vector. The mask restricts memory access to certain lanes and facilitates vectorization of predicated basic blocks.
+
+
+::
+
+ %res = call <4 x double> @llvm.masked.gather.v4f64 (<4 x double*> %ptrs, i32 8, <4 x i1>%mask, <4 x double> <true, true, true, true>)
+
+ ;; The gather with all-true mask is equivalent to the following instruction sequence
+ %ptr0 = extractelement <4 x double*> %ptrs, i32 0
+ %ptr1 = extractelement <4 x double*> %ptrs, i32 1
+ %ptr2 = extractelement <4 x double*> %ptrs, i32 2
+ %ptr3 = extractelement <4 x double*> %ptrs, i32 3
+
+ %val0 = load double, double* %ptr0, align 8
+ %val1 = load double, double* %ptr1, align 8
+ %val2 = load double, double* %ptr2, align 8
+ %val3 = load double, double* %ptr3, align 8
+
+ %vec0 = insertelement <4 x double>undef, %val0, 0
+ %vec01 = insertelement <4 x double>%vec0, %val1, 1
+ %vec012 = insertelement <4 x double>%vec01, %val2, 2
+ %vec0123 = insertelement <4 x double>%vec012, %val3, 3
+
+.. _int_mscatter:
+
+'``llvm.masked.scatter.*``' Intrinsics
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Syntax:
+"""""""
+This is an overloaded intrinsic. The data stored in memory is a vector of any integer or floating point data type. Each vector element is stored in an arbitrary memory addresses. Scatter with overlapping addresses is guaranteed to be ordered from least-significant to most-significant element.
+
+::
+
+ declare void @llvm.masked.scatter.v8i32 (<8 x i32> <value>, <8 x i32*> <ptrs>, i32 <alignment>, <8 x i1> <mask>)
+ declare void @llvm.masked.scatter.v16f32(<16 x i32> <value>, <16 x i32*> <ptrs>, i32 <alignment>, <16 x i1> <mask>)
+
+Overview:
+"""""""""
+
+Writes each element from the value vector to the corresponding memory address. The memory addresses are represented as a vector of pointers. Writing is done according to the provided mask. The mask holds a bit for each vector lane, and is used to prevent memory accesses to the masked-off lanes.
+
+Arguments:
+""""""""""
+
+The first operand is a vector value to be written to memory. The second operand is a vector of pointers, pointing to where the value elements should be stored. It has the same underlying type as the value operand. The third operand is an alignment of the destination addresses. The fourth operand, mask, is a vector of boolean values. The types of the mask and the value operand must have the same number of vector elements.
+
+
+Semantics:
+""""""""""
+
+The '``llvm.masked.scatter``' intrinsics is designed for writing selected vector elements to arbitrary memory addresses in a single IR operation. The operation may be conditional, when not all bits in the mask are switched on. It is useful for targets that support vector masked scatter and allows vectorizing basic blocks with data and control divergency. Other targets may support this intrinsic differently, for example by lowering it into a sequence of branches that guard scalar store operations.
+
+::
+
+ ;; This instruction unconditionaly stores data vector in multiple addresses
+ call @llvm.masked.scatter.v8i32 (<8 x i32> %value, <8 x i32*> %ptrs, i32 4, <8 x i1> <true, true, .. true>)
+
+ ;; It is equivalent to a list of scalar stores
+ %val0 = extractelement <8 x i32> %value, i32 0
+ %val1 = extractelement <8 x i32> %value, i32 1
+ ..
+ %val7 = extractelement <8 x i32> %value, i32 7
+ %ptr0 = extractelement <8 x i32*> %ptrs, i32 0
+ %ptr1 = extractelement <8 x i32*> %ptrs, i32 1
+ ..
+ %ptr7 = extractelement <8 x i32*> %ptrs, i32 7
+ ;; Note: the order of the following stores is important when they overlap:
+ store i32 %val0, i32* %ptr0, align 4
+ store i32 %val1, i32* %ptr1, align 4
+ ..
+ store i32 %val7, i32* %ptr7, align 4
+
+
Memory Use Markers
------------------
-This class of intrinsics exists to information about the lifetime of
+This class of intrinsics provides information about the lifetime of
memory objects and ranges where variables are immutable.
.. _int_lifestart:
This intrinsic is lowered to the ``val``.
+.. _int_assume:
+
+'``llvm.assume``' Intrinsic
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Syntax:
+"""""""
+
+::
+
+ declare void @llvm.assume(i1 %cond)
+
+Overview:
+"""""""""
+
+The ``llvm.assume`` allows the optimizer to assume that the provided
+condition is true. This information can then be used in simplifying other parts
+of the code.
+
+Arguments:
+""""""""""
+
+The condition which the optimizer may assume is always true.
+
+Semantics:
+""""""""""
+
+The intrinsic allows the optimizer to assume that the provided condition is
+always true whenever the control flow reaches the intrinsic call. No code is
+generated for this intrinsic, and instructions that contribute only to the
+provided condition are not used for code generation. If the condition is
+violated during execution, the behavior is undefined.
+
+Note that the optimizer might limit the transformations performed on values
+used by the ``llvm.assume`` intrinsic in order to preserve the instructions
+only used to form the intrinsic's input argument. This might prove undesirable
+if the extra information provided by the ``llvm.assume`` intrinsic does not cause
+sufficient overall improvement in code quality. For this reason,
+``llvm.assume`` should not be used to document basic mathematical invariants
+that the optimizer can otherwise deduce or facts that are of little use to the
+optimizer.
+
+.. _bitset.test:
+
+'``llvm.bitset.test``' Intrinsic
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Syntax:
+"""""""
+
+::
+
+ declare i1 @llvm.bitset.test(i8* %ptr, metadata %bitset) nounwind readnone
+
+
+Arguments:
+""""""""""
+
+The first argument is a pointer to be tested. The second argument is a
+metadata string containing the name of a :doc:`bitset <BitSets>`.
+
+Overview:
+"""""""""
+
+The ``llvm.bitset.test`` intrinsic tests whether the given pointer is a
+member of the given bitset.
+
'``llvm.donothing``' Intrinsic
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Overview:
"""""""""
-The ``llvm.donothing`` intrinsic doesn't perform any operation. It's the
-only intrinsic that can be called with an invoke instruction.
+The ``llvm.donothing`` intrinsic doesn't perform any operation. It's one of only
+two intrinsics (besides ``llvm.experimental.patchpoint``) that can be called
+with an invoke instruction.
Arguments:
""""""""""
projects / oota-llvm.git / blobdiff